View SDED5-001G-NAT_7075595.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

? 2007 sandisk? corporation 1 92-ds-1205-10 mdoc h3 embedded flash drive (efd) featuring embedded trueffs ? flash management software data sheet, may 2008 h ighlights mdoc h3 is an embedded flash drive (efd) designed for mobile handsets and consumer electronics devices. mdoc h3 is the new generation of sandisk?s successful mdoc product family, enabling tens of millions of handsets and other mobile devices since the year 2000. mdoc h3 is a hybrid device combining an embedded thin flash controller and standard flash memory. in addition to the hi gh reliability and high system performance offered by the current mdoc family of products, mdoc h3 offers plug-and-play integration, support for multiple nand technologies and more features such as advanced power management schemes. mdoc h3 uses advanced multi-level cell (mlc) and binary (slc) nand flash technologies, enhanced by sandisk?s proprietary trueffs embedded flash management software running as firmware on the flash controller. the breakthrough in performance, size, cost and design makes mdoc h3 the ideal solution for mobile handsets and consumer electronics manufacturers who require easy integration, fast time to market, high-capacity, small form factor, high-performance and most importantly, highly reliable storage. mdoc h3 enables multimedia driven applications such as music, photo, video, tv, gps, games, email, office and other applications. e mbedded t rue ffs sandisk?s proprietary trueffs flash management software is now embedded within the mdoc h3 device and runs as firmware from the flash controller. legacy mdoc architecture host flash controller flash ++ + mdoc h3 architecture host flash controller flash ++ + legacy mdoc architecture host flash controller flash ++ + host flash controller flash ++ + mdoc h3 architecture host flash controller flash ++ + host flash controller flash ++ + figure 1: trueffs - legacy mdoc vs. mdoc h3 architecture embedded trueffs enables mdoc h3 to fully emulate a hard disk to the host processor,
rev. 1.3 mdoc h3 efd featuring embedded trueffs data sheet 2 92-ds-1205-10 enabling read/write operations that are identical to a standard, s ector-based hard drive. in addition, embedded trueffs employs patented methods, such as virtual mapping, dynamic and static wear-leveling, and automatic block management to ensure high data reliability and maximize flash life expectancy. furthermore, it provides performance enhancements such as multi-plane operations, dma support, burst operation and dual data ram buffering. mdoc h3 extended features are enabled by a small driver that runs on the host side, called doc driver. doc driver provides the host os with a standard block device interface. the combination of embedded trueffs and doc driver enables a pr actically plug & play integration in the system. p lug - and -p lay i ntegration mdoc h3 optimized architecture with embedded trueffs eliminates the need for complicated software integration and testing processes and enables a practically plug-and- play integration in the system. the replacement of one mdoc h3 device with another, of a newer generation, requires virtually no changes to the host. this makes mdoc h3 the perfect solution for platforms and reference designs, as it allows for the utilization of more advanced nand flash technology with minimal integration or qualification efforts. embedded trueffs running from mdoc h3 means there is no need to modify and re- qualify the flash management software on the host system, or update mass production tools. m ultiple f lash s upport mdoc h3 with embedded trueffs enables access to advanced binary slc nand and mlc nand flash technology, making mdoc h3 the only multi-sourced and multi- technology efd. embedded trueffs overcomes slc and mlc nand-related error patterns by using a robust error detection and correction (edc/ecc) mechanism. mdoc h3 optimized architecture with embedded trueffs offers high reliability and high system performance for whatever flash technology or density utilized. m doc h3 p rovides : ? flash disk for both code and data storage ? code and data storage protection ? low voltage: 1.8v core and i/o 3.3v core and 3.3v/1.8v i/o (auto-detect) ? typical current consumption ? turbo mode: 30ma ? power save mode: 20ma ? standby mode: 5ma ? deep power-down mode: 60ua- 110ua ? 1gb (128mb) ? 64gb (8gb) data storage capacity, with device cascading options for up to 128gb (16gb). ? enhanced programmable boot block (32kb) enabling execute in place (xip) functionality using 16-bit access. ? small form factors: ? mdoc h3 1gb/2gb - 115-ball fine-pitch ball grid array (fbga) 9x12mm. ? mdoc h3 4gb/8gb - 115-ball fine-pitch ball grid array (fbga) 10x14mm.
rev. 1.3 mdoc h3 efd featuring embedded trueffs data sheet 3 92-ds-1205-10 ? mdoc h3 8gb/16gb/32gb/64gb - 115-ball fine-pitch ball grid array (fbga) 12x18mm ? ball to ball compatible with mdoc g3/g4/h1 families. ? enhanced performance by implementation of: ? multi-plane operations ? dma support ? burst operation ? dual data ram buffering ? read/write cache ? fast partition configuration ? powerful data integrity with a robust error detection code/erro r correction code (edc/ecc) specifically tailored for the most advanced flash technology. ? strong flash endurance with trueffs advanced flash management software. ? reduced complexity for the host system by moving flash management functionality to the device. ? plug & play integration with the host system, due to embedding trueffs within the device itself. ? support for major mobile operating systems (oss), including symbian os, windows mobile, windows ce, linux and more. ? compatibility with major mobile cpus ? performance: ? sustained write: 4-8 mb/sec. ? sustained read: 15-25 mb/sec p rotection & s ecurity - e nabling ? 16-byte unique identification (uid) number. ? 14 configurable protected partitions for data and code: ? write protected ? read and write protected ? one time programmable (otp) ? protection key and lock# signal ? sticky lock (slock) to lock boot partition ? protected bad block table. r eliability and d ata i ntegrity ? hardware on-the-fly error detection code/error correction code (edc/ecc), based on a bch algorithm, tailored for the most advanced flash technology. ? data integrity after power failure. ? transparent bad-block management. ? dynamic and static wear-leveling. b oot c apability ? 32kb programmable boot block with xip capability to replace boot rom or nor. ? 254kb paged ram ipl ? boot agent for automatic download of boot code to the programmable boot block. ? asynchronous boot mode to enable arm- based cpus, e.g. ti omap, intel pxaxxx, to boot without the need for external glue logic. ? exceptional boot performance with burst operation and dma support enhanced by external clock. h ardware c ompatibility ? configurable interface: simple sram-like or multiplexed address/data interface. ? cpu compatibility, including: ? arm-based cpus ? texas instruments omap, dbb ? marvell pxaxxx family ? infineon xgold family ? analog devices (adi) digital baseband devices ? freescale i.mxxx application processors and i.xx digital baseband devices
rev. 1.3 mdoc h3 efd featuring embedded trueffs data sheet 4 92-ds-1205-10 ? zoran er4525 ? renesas sh mobile ? emp platforms ? qualcomm msmxxxx ? hitachi superh? sh-x ? supports 16 and 32-bit architectures e mbedded t rue ffs s oftware trueffs (true flash file system) is sandisk?s field proven patented flash management software. trueffs is embedded within the mdoc h3 device, providing full block device functionality to the operating system (os) file system via either trueffs 7.1 (for supporting both earlier mdoc products and mdoc h3) or the doc driver. trueffs allows for mdoc h3 to appear to the os as a regular hard drive, while at the same time transparently providing robust flash media management. ? doc driver provides full block device emulation for transparent file system management ? disk-like interface ? dynamic virtual mapping ? automatic bad block management ? dynamic and static wear-leveling ? programming, duplicating and testing tools available in source code c apacity and p ackaging ? 1gb (128mb) ? 64gb (8gb) capacity, with device cascading option for up to two devices (128gb). ? fbga package: 115 balls, 9x12x1.2 mm (width x length x height) ? fbga package: 115 balls, 10x14x1.2 mm (width x length x height) ? fbga package: 115 balls, 12x18x1.4 mm and 12x18x1.2 mm (width x length x height) ? ball-out compatible with mdoc g3, g4 and h1 products: refer to migration guide mdoc g3-p3 g3p3-lp g4 h1 to mdoc h3 for further details. o perating e nvironment ? wide os support, including: ? symbian os ? windows mobile ? windows ce ? linux ? nucleus ? ose ? palmos ? doc driver software development kit (sdk) for quick and easy support of proprietary oss or os-less environments.
rev. 1.3 mdoc h3 efd featuring embedded trueffs data sheet 5 92-ds-1205-10 r evision h istory doc. no revision date description reference 0.1 january 2006 preliminary version rsrvd balls left floating changed from a recommendation to a requirement section 2 demux (standard) i/f ball h9 changed from rsrvd to vss section 2.2 ballout change ? some nc balls removed, resulting in 115 balls for all products section 2.2 ball h2 changed from dpd to a0 sections 2.2 and 2.3 details on internal pull up and pull down resistors added sections 2.2.2 and 2.3.2 dpd signal removed (replaced with a0, which should be connected to cpu a0 or to vss) sections 2, 2.2.2 and 2.3.2 balls g1,h1,j1,k1 marked as reserved ball g4 changed from rsrvd to vccq sections 2.2.2 and 2.3.2 ball d9 changed from nc to rsrvd section 2.3.2 modes of operation diagram updated section 5 ?normal mode? name changed to ?turbo mode? section 5 8kb address space settings added section 6.5 added register addresses for 8kb address space section 7 burst mode can only be used in conjunction with mdoc h3 dma functionality section 9.8.2 operating conditions updated section 10.3 asynchronous boot mode timing diagram added section 10.3.1 multiplexed timing updated section 10.3.4 section 10.3.5 power up timing updated section 10.3.11 92-ds-1205-10 0.2 june 2006 mechanical drawing updated (removed balls from 12x18mm drawing) section 10.4.3
rev. 1.3 mdoc h3 efd featuring embedded trueffs data sheet 6 92-ds-1205-10 doc. no revision date description reference ordering information modified section 11 refer to standard interface as demux entire document current/power consumption numbers modified highlights and section 10.2.3 number of partitions available changed from 10 to 14 highlights and section 2.1 note that clk should be half- frequency at power-save mode section 10.3 added clarifications about capacitor requirements for different voltage configurations section 9.5 marking section added section 0 busy#, dmarq# and irq#: changed from cmos 3-state to cmos output and added clarification about pull ups table 1 and table 2 key size modified section 4 modes of operation section enhanced section 5 mdoc h3 registers section updated section 7 gpio_timer and warm_rst# description updated entire document synchronous burst operation description modified section 9.8.2 storage temperature modified and section enhanced section 10.2.1 demux asynchronous read access time modified; tdh max added; tah, tw(oeh) and tw(oel) added section 10.3.2 demux asynchronous write timing ? tw(wel) and tw(weh) added section 10.3.2 demux burst read minimal clock cycle time modified section 10.3.6 mechanical dimensions tolerance corrected section 10.4 power up timing section updated section 10.3.12 max input fall and rise time info added section 10.3.1 1.0 february 2007 figure modified figure 9
rev. 1.3 mdoc h3 efd featuring embedded trueffs data sheet 7 92-ds-1205-10 doc. no revision date description reference add 10x14 package size sections 2.2, 2.3 paragraph revisited section 3.5 change requirement for capacitor on vcc section 9.5 modified comment 14 add comment 17 section 9.5 added drawings to depict power connectivity section 9.5 added temperature range for new products section 10.1.1 dc characteristics: added disclaimer for icc / iccs parameters for new products section 10.2.3 updated parameter tcesu sections 10.3.6, 10.3.8 add 10x14 package mechanical description section 10.4.2 added note on ball size change of new products sections 10.4.1, 10.4.3 ordering info section updated section 11 added new sandisk top marking section 12 128kb window updated section 6.4 1.1 april/may 2007 updated dma transfer timing diagram section 10.3.9 remove internal pull up of #avd signal section 2.3.2 updated icc max values for new products table 9 multiplexed synchronous write timing updated section 10.3.4 mechanical dimension updated: ball size reduced for 9x12 package section 10.4.1 marking section revised section 12 burst mode section revised section 9.8.2 92-ds-1205-10 1.2 november 2007 mdoc 8gb product added entire document ordering information updated 11 92-ds-1205-10 1.3 may 2008 power failure management updated section 6.3.4
rev. 1.3 mdoc h3 efd featuring embedded trueffs data sheet 8 92-ds-1205-10 t able of c ontents 1. introduction................................................................................................................... ........... 12 2. product overview ............................................................................................................... ..... 13 2.1 product description .......................................................................................................... 13 2.2 demux (standard) interface ............................................................................................. 14 2.2.1 9x12/10x14/12x18 fbga ball diagrams ............................................................................ 14 2.2.2 9x12/10x14/12x18 fbga signal desc ription...................................................................... 16 2.2.3 system in terface ............................................................................................................... .. 19 2.3 multiplexed interface......................................................................................................... 19 2.3.1 9x12/10x14/12x18 fbga ball di agram .............................................................................. 19 2.3.2 9x12/10x14/12x18 fbga signal desc ription...................................................................... 21 2.3.3 system in terface ............................................................................................................... .. 23 3. theory of operation ............................................................................................................ .... 25 3.1 overview....................................................................................................................... .... 25 3.2 host interface ................................................................................................................. .. 26 3.2.1 demux (nor-like) interface............................................................................................... 26 3.2.2 multiplexed interface .......................................................................................................... . 26 3.2.3 serial in terface ............................................................................................................... ..... 27 3.3 host agent ..................................................................................................................... ... 27 3.3.1 host protocol.................................................................................................................. ..... 27 3.3.2 boot block (xip) ............................................................................................................... ... 27 3.4 boot agent ..................................................................................................................... ... 27 3.5 error detection code/error correction code (edc/ecc) ................................................ 28 3.6 block device management ............................................................................................... 28 4. data protection and security-enabling features .................................................................. 29 4.1.1 read/write-protect ed partitions .......................................................................................... 29 4.1.2 lock# signal ................................................................................................................... ... 29 4.1.3 sticky lock (slock) .......................................................................................................... 29 4.1.4 unique identificati on (uid) number .................................................................................... 30 4.1.5 one-time programmabl e (otp) pa rtitions......................................................................... 30 5. mdoc h3 modes of operation ............................................................................................... 31 5.1 reset state .................................................................................................................... ... 32 5.2 turbo mode ..................................................................................................................... . 32 5.3 power save mode ............................................................................................................ 32 5.4 standby mode................................................................................................................... 32 5.5 deep power-down mode.................................................................................................. 33
rev. 1.3 mdoc h3 efd featuring embedded trueffs data sheet 9 92-ds-1205-10 6. embedded trueffs technology............................................................................................ 34 6.1 general description .......................................................................................................... 34 6.2 operating system support ............................................................................................... 34 6.3 doc driver software development kit (sdk).................................................................. 35 6.3.1 file mana gement ................................................................................................................ 35 6.3.2 bad-block managem ent...................................................................................................... 35 6.3.3 wear-leveling .................................................................................................................. ... 35 6.3.4 power failure management ................................................................................................ 36 6.3.5 error detection/correction .................................................................................................. 36 6.3.6 special features through i/o control (ioctl ) mechanism................................................ 36 6.3.7 compatib ility.................................................................................................................. ...... 37 6.4 128kb memory window ................................................................................................... 37 6.5 8kb memory window ....................................................................................................... 39 7. mdoc h3 registers .............................................................................................................. .. 40 7.1 definition of terms............................................................................................................ 40 7.2 reset values ................................................................................................................... . 40 7.3 registers description........................................................................................................ 41 7.3.1 paged ram comm and register......................................................................................... 41 7.3.2 paged ram select register ............................................................................................... 41 7.3.3 paged ram unique id download r egister ........................................................................ 42 7.3.4 chip identification (i d) register [0:1] .................................................................................. 42 7.3.5 burst mode control regi sters (read & write) .................................................................... 42 7.3.6 burst write mode exit r egister ........................................................................................... 43 7.3.7 dpd wakeup tri gger register............................................................................................ 43 7.3.8 dpd activati on register...................................................................................................... 44 7.3.9 dma control register ......................................................................................................... 44 7.3.10 dma negation register ...................................................................................................... 45 7.3.11 software lock register ....................................................................................................... 45 7.3.12 endian contro l regi ster ...................................................................................................... 46 8. booting from mdoc h3 .......................................................................................................... 47 8.1 introduction ................................................................................................................... .... 47 8.1.1 asynchronous boot mode ................................................................................................... 48 8.1.2 paged ram boot ................................................................................................................ 48 9. design considerations .......................................................................................................... . 49 9.1 general guidelines ........................................................................................................... 49 9.2 configuration .................................................................................................................. .. 49 9.3 demux (standard) interface ............................................................................................. 49 9.4 multiplexed interface......................................................................................................... 50
rev. 1.3 mdoc h3 efd featuring embedded trueffs data sheet 10 92-ds-1205-10 9.5 mdoc h3 power supply connectivity ............................................................................. 51 9.6 connecting control signals .............................................................................................. 55 9.6.1 demux inte rface................................................................................................................ .. 55 9.6.2 multiplexed interface .......................................................................................................... . 55 9.7 implementing the interrupt mechanism ............................................................................ 56 9.7.1 hardware conf iguration ...................................................................................................... 56 9.7.2 software conf igurat ion........................................................................................................ 56 9.8 dma and burst operation................................................................................................. 56 9.8.1 dma operation .................................................................................................................. . 56 9.8.2 synchronous burs t operation ............................................................................................. 57 9.9 device cascading............................................................................................................. 60 9.10 platform-specific issues ................................................................................................... 61 9.10.1 wait state..................................................................................................................... ....... 61 9.10.2 big and little e ndian systems ............................................................................................ 61 9.10.3 busy signal .................................................................................................................... ..... 61 9.10.4 working with 16/ 32-bit systems ......................................................................................... 61 9.11 design environment ......................................................................................................... 63 10. product specifications......................................................................................................... ... 64 10.1 environmental specifications............................................................................................ 64 10.1.1 operating te mperat ure....................................................................................................... 64 10.1.2 thermal charac teristics ...................................................................................................... 64 10.1.3 humidity ....................................................................................................................... ....... 64 10.2 electrical specifications .................................................................................................... 64 10.2.1 absolute maxi mum ratings ................................................................................................ 64 10.2.2 capacitance .................................................................................................................... .... 65 10.2.3 dc characte ristics ............................................................................................................. . 65 10.3 timing specifications........................................................................................................ 68 10.3.1 operating co nditions .......................................................................................................... 68 10.3.2 demux asynchrono us read timing ................................................................................... 69 10.3.3 demux asynchronous write timing.................................................................................... 70 10.3.4 multiplexed asynchro nous read timing............................................................................. 70 10.3.5 multiplexed asynchro nous write timing............................................................................. 71 10.3.6 demux burst re ad timing .................................................................................................. 72 10.3.7 demux burst wri te timing .................................................................................................. 73 10.3.8 multiplexed burs t read ti ming ........................................................................................... 74 10.3.9 dma request ti ming diag ram ........................................................................................... 75 10.3.10 spi timing..................................................................................................................... ...... 76 10.3.11 power suppl y sequence..................................................................................................... 77 10.3.12 power-up timing ................................................................................................................ 77
rev. 1.3 mdoc h3 efd featuring embedded trueffs data sheet 11 92-ds-1205-10 10.4 mechanical dimensions.................................................................................................... 79 10.4.1 mdoc h3 1gb (128 mb)/2gb (256mb) .............................................................................. 79 10.4.2 mdoc h3 4gb (512 mb)/8gb (1gb) .................................................................................. 80 10.4.3 mdoc h3 8gb (1gb)/ 16gb (2gb )/ 32gb (4gb) / 64gb (8gb)........................................ 81 11. ordering information........................................................................................................... .... 82 12. markings....................................................................................................................... ............ 83 12.1 mdoc h3 1gb (128mb)................................................................................................... 83 12.2 mdoc h3 2gb (256mb)/ 4gb (512mb)/ 8gb (1gb)/ 16gb (2gb)/ 32gb (4gb) / 64gb (8gb) .......................................................................................................................... ............... 84 disclaimer of liability ........................................................................................................ ........... 85
rev. 1.3 introduction mdoc h3 efd featuring embedded trueffs data sheet ? 2007 sandisk? corporation 12 92-ds-1205-10 1. i ntroduction this data sheet includes the following sections: section 1: introduction and overview of data sheet contents section 2: product overview, including a brief product description, ball diagrams and signal descriptions section 3: theory of operation for the major building blocks section 4: data protection and security enabling features overview section 5: detailed description of modes of operation section 6: embedded trueffs technology overview, including power failure management and 8kb/128kbyte memory window section 7: mdoc h3 register descriptions section 8: overview of how to boot from mdoc h3 section 9: hardware and software design considerations section 10: environmental, electrical, tim ing and product specifications section 11: information on ordering mdoc h3 section 12: marking information for additional information on sandisk?s flash di sk products, please contact one of the offices listed on the back page.
rev. 1.3 product overvie w mdoc h3 efd featuring embedded trueffs data sheet 13 92-ds-1205-10 2. p roduct o verview 2.1 product description mdoc h3 is the latest addition to sandisk?s mdoc product family. mdoc h3, packaged in a small fbga package and offering densities rang ing from 1gb (128mb) to 16gb (2gb), is a hybrid device with an embedded flash controlle r and high capacity flash memory. it uses advanced flash technologies, enhanced by sa ndisk?s proprietary trueffs embedded flash management software. all mdoc h3 devices are ball to ball compatib le. the replacement of one mdoc h3 device with another of a newer generation requires virt ually no changes to the host. this makes mdoc h3 the perfect solution for platforms and referen ce designs, as it allows for the utilization of more advanced nand flash techno logy and new mdoc functionality with minimal integration efforts. mdoc h3 has a 32kb programmable boot block. this block provides execute in place (xip) functionality, enabling mdoc h3 to replace the boot device and to function as the only non-volatile memory device on-boar d. eliminating the need for an additional boot device reduces hardware expenditures, board real estate, programming time, and logistics. the paged ram ipl feature separates the boot block into sections: the first section provides constant data, while the other sections (up to 254kb) can be loaded with data that is automatically downloaded from the flash. one application of this feature is to support processors? secure boot requirements. sandisk?s proprietary trueffs flash manageme nt software overcomes nand-related error patterns by using a robust error detection and correcti on (edc/ecc) mechanism. furthermore, it provides performance enhancements such as multi-plane operations, dma support, burst operation and dual data ram buffering. the new generation of patented flash management software, embedded trueffs, is run on the embedded thin controller of the mdoc h3 devi ce, instead of on the host. this results in improvements in performance, ease of integr ation and overall uti lization of latest nand technologies. embedded trueffs guarantees high reli ability and isolates a ll the complexity of flash management from the host sw. embedded trueffs enables mdoc h3 to fully em ulate a hard disk to the host processor, enabling read/write operations that are identical to a standard, sector-based hard drive. in addition, embedded trueffs employs patented methods, such as virtual mapping, dynamic and static wear-leveling, and automatic bad block mana gement to ensure high data reliability and maximize flash life expectancy. mdoc h3 extended features are enabled by a small driver that runs on the host side, called doc driver. doc dr iver provides the host o/s with a standard block device interface, together with apis fo r mdoc h3?s extended features. the combination of embedded trueffs and doc driver practi cally enables plug and play integration. mdoc h3 offers extended content protection an d security-enabling features. up to 14 write protected, read-and-write protected, or one time programmable (otp) partitions can be configured independently for ma ximum design flexibility. a 16-byt e unique id (uid) identifies each device, eliminating the need for a separate id device on the motherboard. the combination
rev. 1.3 product overvie w mdoc h3 efd featuring embedded trueffs data sheet 14 92-ds-1205-10 of these features enables mdoc h3 to implement better security schemes to protect the code and data it stores. mdoc h3 can be configured to work with either demux (standard) interface or multiplexed (mux) interface. using a multiplexed interface wher e data and address lines are multiplexed on the same lines, reduces the number of signals required to connect mdoc h3 to the cpu. the combination of unique h3 design, late st nand technology and embedded trueffs results in a low-cost, minimal-sized flash disk that ac hieves unsurpassed reliab ility levels, enhanced performance and ease of integration. this breakthrough in performance, size, cost a nd design makes mdoc h3 the ideal solution for mobile handsets and consumer electronics manuf acturers who require easy integration, fast time to market, high-capacity, small size, high-performa nce and, above all, high-reliability storage to enable multimedia driven applications such as music, photo, video, tv, gps, games, email, office and other applications. mdoc h3 offers advanced power consump tion management throughout the selection of different operating modes. the operating modes of the mdoc h3 device are designed to be easily controlled by the chipset and doc driver to ensure optimal battery life in mobile devices. mdoc h3 can be placed in any of the following four operating modes: ? turbo mode - while in turbo mode, device in ternal clocks are optimized for maximal performance. ? power save mode ? while in power save mode , device internal clocks are optimized to balance between device performance and power consumption. ? standby mode ? while in standby mode, the cl ock of most internal cores is either disconnected or reduced to a minimum. there is no wake-up time penalty. ? deep power down (dpd) mode - while in deep power-down m ode, device quiescent power dissipation is reduced by disabling in ternal high current consumers (e.g. flash, voltage regulators, input buffers, oscillator etc.) the power management flexibility of mdoc h3 allows for the syst em designers to substantially reduce the power consumption of the mdoc devi ce, based on the requirements of the mobile device, to effectively and cons iderably prolong battery life. 2.2 demux (standard) interface 2.2.1 9x12/10x14/12x18 fbga ball diagrams figure 2 shows the mdoc h3 115 ball demux interface ball diagram. to ensure proper device functiona lity, balls marked rsrvd are reserved for future use and should be connected as described in table 1, section 2.2.2. note: mdoc h3 is designed as a ball to ball compatible with mdoc g3, g4 and h1 products, assuming that the latter were integrated acco rding to the guidelines in the migration guide. refer to migration guide mdoc g3-p3 g3p3-lp g4 h1 to mdoc h3 , for further information.
rev. 1.3 product overvie w mdoc h3 efd featuring embedded trueffs data sheet 15 92-ds-1205-10 9x12/10x14/12x18 fbga package figure 2: demux interface ball diagram fo r 9x12, 10x14 and 12x18 fbga ? top view d 5 d 2 d 8 d 11 d 14 a 9 a 13 c - lock # a 2 busy # rsrvd a 5 warm _ rst # d 4 d 15 d 3 ce # d 9 d 13 vccq d 0 sclk rsrvd d 10 vcc d 12 rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd nc nc rsrvd nc a 8 vss vcc 2 we# a 11 a 7 a 6 c + a 12 vcc 1 rstin # a 14 a 15 a 3 scs # a 1 irq # id 0 a 4 vccq a 10 nc nc rsrvd vss d 1 rsrvd d 6 nc nc so nc nc nc rsrvd nc nc nc nc nc nc nc nc rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd a 16 si vss rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd gpio _ timer clk dmarq # a 0 rsrvd vss oe # d 7 rsrvd 9 10 1 2 3 4 5 6 7 8 a b c d e f g h j k l m n p
rev. 1.3 product overvie w mdoc h3 efd featuring embedded trueffs data sheet 16 92-ds-1205-10 2.2.2 9x12/10x14/12x18 fbga signal description mdoc h3 (115 ball) package ball designations are li sted in the signal desc riptions, presented in logic groups, in table 1. table 1: demux interface signal description signal ball no. signal type 1 description signal direction system interface a[16:15] a[14:13] a[12:11] a[10:8] a[7:4] a[3:0] f10, e10 e4, f4 e8, d8 g7, f7, d7 d3, e3, f3, g3 e2, f2, g2, h2 a[12:0] st a[16:13]in/pd address bus. input d[7:6] d[5:3] d[2:0] k8, h7 l7, j6, j5 l4, h4, k3 st data bus, low byte. input/output d[15:14] d[13:12] d[11:8] j8, l8 j7, k7 l5, k4, j4, l3 st data bus, high byte. input/output ce# j2 st chip enable, active low. input oe# j3 st output enable, active low. input we# d6 st write enable, active low input configuration gpio_timer e1 st/pu rsrvd. this signal may be left floating or pulled up. input/output id0 g8 pd identification. configuration control to support up to two chips cascaded in the same memory window. chip 1: id0 = vss chip 2: id0 = vccq input lock# f8 st lock, active low. when active, provides full hardware data protection of selected partitions. input control warm_rst# j9 st/pu rsrvd. this signal may be left floating or pulled up. input busy# f5 cmos output busy. active low. indicates that mdoc is initializing and should not be accessed 5 output rstin# e5 st/pu reset, active low. input
rev. 1.3 product overvie w mdoc h3 efd featuring embedded trueffs data sheet 17 92-ds-1205-10 signal ball no. signal type 1 description signal direction clk l6 st external clock input used for burst mode data transfers. if not used may be left floating. input dmarq# h8 cmos output dma request. if not used may be left floating5. output irq# g9 cmos output interrupt request. active low. if not used may be left floating. 5 output serial interface scs# g10 st/pu/cmos 3- state serial interface chip select. active low. if not used may be left floating. input/output so h10 st/pu/cmos 3- state serial interface data out (in serial slave mode) 2 . if not used may be left floating. output/input si j10 st/pu/cmos 3- state serial interface data in (in serial slave mode) 2 . if not used may be left floating. input/output sclk k10 st/pu/cmos 3- state serial interface clock. if not used may be left floating. input/output power vcc2 d5 - internal supply. supply vcc1 e7 - internal supply. supply vccq k6, g4 - i/o power supply. supply vcc k5 - device supply. supply vss d4, h3, h9, k9 - ground. all vss balls must be connected. supply c+ e6 - c1 capacitor positive terminal 3 . supply c- f6 - c1 capacitor negative terminal 3 . supply
rev. 1.3 product overvie w mdoc h3 efd featuring embedded trueffs data sheet 18 92-ds-1205-10 signal ball no. signal type 1 description signal direction reserved c2, c3, c4, c5, c6, c7, c8, c9, c10, d1, d2, d9, d10, e9, f1, f9, g1, h1, j1, k1, k2, l2, l9, l10, m2, m3, m4, m5, m6,m7, m8, m9, m10 - all reserved signals are not connected internally, and if not identified in this document then it is recommended to leave them floating to guarantee forward compatibility with future products. they should not be connected to arbitrary signals, and must not be connected to gnd p1 st/pu test data in (jtag). used for dedicated developer product only 4 . input m1 cmos output test data out (jtag). used for dedicated developer product only 4 . output l1 st/pu test mode select (jtag) used for dedicated developer product only 4 . input rsrvd n1 st/pu test clock (jtag). used for dedicated developer product only 4 . input mechanical nc a1, a2, a9, a10, b1, b2, b9, b10, g5, g6, h5, h6, n2, n9, n10, p2, p9, p10 - not connected. 1. the following abbreviations are used: st - schmitt trigger input . in/pd ? cmos input with internal pull down resistor (77k ? to 312k ? ; 135k ? typical), which is enabled only when 8kb memory window is in use, st/pu - schmitt trigger input with internal pull up resistor (95k ? to 261 k ? ; 149 k ? typical). 2. when mdoc h3 is used as a master device, so is used for serial interface data in, a nd si is used for serial interface data out. 3. the capacitor is required only for 1.8v core a nd 1.8v i/o configurati on. please see section 9.5 for further details. 4. the rsrvd jtag balls will only be enabled on special versions of the mdoc h3 devices that will be used for debugging severe sys tem problems. in order to support this feature, the jtag balls should be brought out to a separate header or test points. the jtag rsrvd balls must not be connected to the jtag scan chain that is used for the re st of the pcb. if not used they should be left float ing. 5. busy#, dmarq# and irq# should not be pulle d up to any voltage higher than vccq. a pull- up resistor is required if this pin will be connected to an input. a 10k ohm resistor to vccq is recomme nded, however the exact value depe nds on system power, timing and s ignal integrity requirements.
rev. 1.3 product overvie w mdoc h3 efd featuring embedded trueffs data sheet 19 92-ds-1205-10 2.2.3 system interface see figure 3 for a simplified i/o diagram of a demux interface to mdoc h3. the power connections and capacitors in this diagram are for illustration only. for detailed recommendations regarding power connections and required capaci tors, please refer to section 9.5. for power connectivity please refer to mdoc h3 power supply conn ectivity in section 9.5. figure 3: demux interface simplified i/o diagram 2.3 multiplexed interface 2.3.1 9x12/10x14/12x18 fbga ball diagram figure 4 shows the mdoc h3 115 ball multiplexe d interface ball diagram. to ensure proper device functionality, balls marked rsrvd are rese rved for future use and should be connected as described in table 2, section 2.3.2. note: mdoc h3 designed as a ball to ball compatible with mdoc g3, g4 and h1 products, assuming that the latter were integrated according to the gui delines in the migration guide. refer to mdoc g3-p3 g3p3-lp g4 and h1 to mdoc h3 migration guide , for further information.
rev. 1.3 product overvie w mdoc h3 efd featuring embedded trueffs data sheet 20 92-ds-1205-10 9x12/10x14/12x18 fbga package figure 4 : multiplexed interface ball diag ram for 9x12/10x14/12x18 fbga ? top view a d 5 a d 2 a d 8 a d 11 a d 14 vss vss c - lock # vss busy # rsrvd vss warm _ rst # a d 4 a d 15 a d 3 ce # a d 9 a d 13 vccq a d 0 sclk rsrvd a d 10 vcc a d 12 rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd nc nc rsrvd nc vss vss vcc 2 we# vss vss vss c + vss vcc 1 rstin # vss vss vss scs # vss irq # id 0 vss vccq vss nc nc rsrvd a vd # a d 1 rsrvd a d 6 nc nc so nc nc nc rsrvd nc nc nc nc nc nc nc nc rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd vss si vss rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd rsrvd gpio _ timer clk dmarq # vss vss oe # a d 7 rsrvd rsrvd a b c d e f g h j k l m n p 9 10 1 2 3 4 5 6 7 8
rev. 1.3 product overvie w mdoc h3 efd featuring embedded trueffs data sheet 21 92-ds-1205-10 2.3.2 9x12/10x14/12x18 fbga signal description mdoc h3 fbga related ball designations are listed in the signal descripti ons, presented in logic groups, in table 2. table 2: signal descriptions for multiplexed interface signal ball no. signal type 1 description signal direction system interface ad[15:12] ad[11:8] ad[7:4] ad[3:0] j8, l8, j7, k7 l5, k4, j4, l3 k8, h7, l7,j6 j5, l4, h4, k3 st multiplexed bus. address and data signals. input ce# j2 st chip enable, active low. input oe# j3 st output enable, active low. input we# d6 st write enable, active low input configuration gpio_timer e1 st/pu rsrvd. this signal may be left floating or pulled up. input/output avd# h9 st address valid strobe. set multiplexed interface. input id0 g8 pd identification. configuration control to support up to two chips cascaded in the same memory window. chip 1: id0 = vss chip 2: id0 = vccq input lock# f8 st lock. active low. when active, provides full hardware data protection of selected partitions. input control warm_rst# j9 st/pu rsrvd. this signal may be left floating or pulled up. input busy# f5 cmos output busy. active low. indicates that mdoc is initializing and should not be accessed. 5 output rstin# e5 st/pu reset, active low. input clk l6 st external clock input used for burst mode data transfers. if not used may be left floating. input dmarq# h8 cmos output dma request. if not used may be left floating. 5 output irq# g9 cmos output interrupt request. active low. if not used may be left floating. 5 output
rev. 1.3 product overvie w mdoc h3 efd featuring embedded trueffs data sheet 22 92-ds-1205-10 signal ball no. signal type 1 description signal direction serial interface scs# g10 st/pu/cmos 3-state serial interface chip select. active low. if not used may be left floating. input/output so h10 st/pu/cmos 3-state serial interface data out (in serial slave mode) 2 . if not used may be left floating. output/input si j10 st/pu/cmos 3-state serial interface data in (in serial slave mode) 2 . if not used may be left floating. input/output sclk k10 st/pu/cmos 3-state serial interface clock. if not used may be left floating. input/output power vcc2 d5 - internal supply. supply vcc1 e7 - internal supply. supply vccq k6, g4 - i/o power supply. supply vcc k5 - device supply. supply vss d3, d4, d7, d8, e2, e3, e4 e8, e10, f2, f3, f4, f7, f10, g2, g3, g7, h2, h3, k9, - ground. all vss balls must be connected. supply c+ e6 - c1 capacitor positive terminal 3 . supply c- f6 - c1 capacitor negative terminal 3 . supply
rev. 1.3 product overvie w mdoc h3 efd featuring embedded trueffs data sheet 23 92-ds-1205-10 signal ball no. signal type 1 description signal direction reserved c2, c3, c4, c5, c6, c7, c8, c9, c10, d1, d2, d9, d10, e9, f1, f9, g1, h1, j1, k1, k2, l2, l9, l10, m2, m3, m4, m5, m6,m7, m8, m9, m10 - all reserved signals are not connected internally, and if not identified in this document then it is recommended to leave them floating to guarantee forward compatibility with future products. they should not be connected to arbitrary signals. p1 st/pu test data in (jtag). used for dedicated developer product only 4 . input m1 cmos output test data out (jtag). used for dedicated developer product only 4 . output l1 st/pu test mode select (jtag) used for dedicated developer product only 4 . input rsrvd n1 st/pu test clock (jtag). used for dedicated developer product only 4 . input mechanical nc a1, a2, a9, a 10, b1, b2, b9, b10, g5, g6, h5, h6, n2, n9, n10, p2, p9, p10 - not connected. 1. the following abbreviations are used: st - schmidt trigger input. in/pd ? cmos input with internal pull down resistor (77k ? to 312k ? ; 135k ? typical), which is enabled only when the 8kb memory window is in use, st/pu - schmitt trigger input with internal pull up resistor (95k ? to 261 k ? ; 149 k ? typical). 2. when mdoc h3 is used as a master device, so is used for serial interface data in, and si used for serial interface data out. 3. the capacitor is required only for 1.8v core a nd 1.8v i/o configurati on. please see section 9.5 for further details. 4. the rsrvd jtag balls will only be enabled on special versions of the mdoc h3 devices that will be used for debugging severe sy stem problems. in order to support this feature, the jtag balls should be brought out to a separate header or test points. the jta g rsrvd balls must not be connected to the jtag scan chain that is used for the re st of the pcb. if not used they should be left floati ng. 5. busy#, dmarq# and irq# should not be pulle d up to any voltage higher than vccq. a pull- up resistor is required if this pin will be connected to an input. a 10k ohm resistor to vccq is recomme nded, however the exact value depe nds on system power, timing and s ignal integrity requirements. 2.3.3 system interface see figure 5 for a simplified i/o diagram of multiplexed interface mdoc h3. the power connections and capacitors in this diagram are for illustration only. for detailed recommendations regarding power connections a nd required capacitors, please refer to section 9.5.
rev. 1.3 product overvie w mdoc h3 efd featuring embedded trueffs data sheet 24 92-ds-1205-10 for power connectivity please refer to mdoc h3 power supply conn ectivity in section 9.5. figure 5: multiplexed interface simplified i/o diagram
rev. 1.3 theory of operation mdoc h3 efd featuring embedded trueffs data sheet 25 92-ds-1205-10 3. t heory of o peration 3.1 overview mdoc h3 consists of the following ma jor functional blocks, as shown in figure 6. figure 6: simplified block diagram these components are described briefly below a nd in more detail in the following sections. ? host if ? host physical interface block. incl udes the following interfaces: demux (standard), multiplexed, and serial. ? host agent ? logical host interface supporting th e host protocol and programmable boot block with xip functionality. ? flash partition management ? high level management of the flash media, managing flash logical parti tions, and their attributes. ? flash bd management ? management of the flash media at a block device level, primarily performing logical to physical address translation. ? boot agent ? management of host boot sequence ? loading of boot code from flash media upon power up. ? ecc / edc - error detection and error correcti on codes (edc/ecc) - on-the-fly flash error handling. ? data buffer ? 4kb dual-port ram memory, used as a pipeline buffer, for enhanced data transfer rate. ? flash agent ? provides high level flash management functions and sequences for flash control and error condition handling.
rev. 1.3 theory of operation mdoc h3 efd featuring embedded trueffs data sheet 26 92-ds-1205-10 ? flash if ? physical interface to the flash media. ? power and timing ? analog and clock circuits to provide power and timing for the h3 controller and flash. ? embedded cpu ? runs embedded trueffs sw and mdoc h3 controller firmware. 3.2 host interface 3.2.1 demux (nor-like) interface the host interface block provides an easy-to-i ntegrate nor-like (also sram and eeprom- like) interface to mdoc h3, enabling various cp u interfaces, such as a local bus, isa bus, nor interface, sram interface, eeprom interface or any other compatible interface. in addition, the nor-like interface enables direct access to the programmable boot block to permit xip (execute-in-place) functionality during system initialization. a1-a16 address lines enable access to the md oc h3 128kb memory window. when migrating from mdoc g3/g4/h1 without changing the pcb, thus using only a1-a12 address lines, mdoc h3 exports 8kb memory window, like in mdoc g3/g4 and h1. the chip enable (ce#), write enable (we#) and output enable (oe#) signals trigger read and write cycles. a write cycle occurs while bo th the ce# and the we# inputs are asserted. similarly, a read cycle occurs while both the ce # and oe# inputs are asserted. note that mdoc h3 does not require a clock signal. the ce#, we # and oe# signals trigger the controller (e.g., system interface block, bus control a nd data pipeline) and flash access. the reset-in (rstin#) and busy (busy#) cont rol signals are used in the reset phase. the interrupt request (irq#) signal is used to indicate completion of assorted operations. using this signal frees the cpu to run other tasks, continuing read/write ope rations with mdoc h3 only after the irq# signal has been asserted and an interrupt ha ndling routine (implemented in the os) has been called to retu rn control to the doc driver. the dmarq# output is used to control dma ope rations, and the clk input is used to support burst operation when reading flash data. see section 10.3 for further information. 3.2.2 multiplexed interface in this configuration, the address and data si gnals are multiplexed. the avd# input is driven by the host avd# signal, and the d[15:0] signals, used for both address inputs and data, are connected to the host ad[15:0] bus. while avd# is asserted, the host drives ad[15:0] with bits [16:1] of the address. this interface is automatically used when a fa lling edge is detected on avd#. this edge must occur after rstin# is de-asserted and before the first read or write cycle to the controller.
rev. 1.3 theory of operation mdoc h3 efd featuring embedded trueffs data sheet 27 92-ds-1205-10 3.2.3 serial interface the serial interface (spi) provides mdoc h3 a secondary interface with debug and programming capabilities. mdoc h3 spi interface is configured as slave. all four combinations of clock phase (cpha) and clock polarity (cpol) which are defined by the spi specification are supported. the serial interface supports two usage scenarios: 1. debug port: allowing the host with an spi interface to read debug messages. 2. format and program port: allowing a programme r to use this port in order to format and program the device. the serial protocol debug port provides a means fo r the serial interface (s pi slave) to queue and transmit debug messages to a host equipped with an spi interface. all transfers are performed in multiples of 8 bits, with the msb of each byte transmitted first. 3.3 host agent 3.3.1 host protocol block of registers and logic required for implementing bloc k device operations over the host interface. this block implements a set of complex transactions required for operating the mdoc h3 device. these transactions include data stor age operations as well as device configuration and management. 3.3.2 boot block (xip) the programmable boot block with xip functionality enables mdoc h3 to act as a boot device (in addition to performing flash disk data storage functions). this eliminates the need for expensive, legacy nor flash or a ny other boot device on the motherboard. the programmable boot block is 32kb in size. the boot agent, described in the next section, is responsible for copying the boot code/dat a from the flash into the boot block. 3.4 boot agent upon power-up or when the rstin# signal is de-asserted, the boot agent automatically downloads the initial program loader (ipl) to the programmable boot block. the ipl contains the code for starting the host boot process. the download process is quick, and is designed so that when the cpu accesses mdoc h3 for code ex ecution, the ipl code is already located in the programmable boot block. during the download proce ss, mdoc h3 does not respond to read or write accesses. host systems must therefore observe the requirements described in section 10.3.12. during the download process, mdoc h3 asserts th e busy# signal to indicat e to the system that it is not yet ready to be acce ssed. once busy# is de-asserted, th e system can access mdoc h3. note that after ipl is loaded and busy# is de -asserted, the boot agent continues to download the embedded trueffs from flash to the mdoc h3 internal ram, and then executes it. downloading the embedded trueffs is done in pa rallel to the host system accessing the ipl
rev. 1.3 theory of operation mdoc h3 efd featuring embedded trueffs data sheet 28 92-ds-1205-10 code. during the time between busy# signal de-assertion and comple ting the download of embedded trueffs, mdoc h3 will respond only to accesses to the xip boot block (including paged ram accesses) in order to facili tate completion of the ipl execution. once embedded trueffs is loaded, executed and has completed its media mount process, mdoc h3 is ready to be used as a fully functional storage device. 3.5 error detection code/erro r correction code (edc/ecc) since nand-based flash is prone to errors, it requires unique error-handling capabilities to ensure required reliability. sandisk?s tr ueffs technology, embedded within mdoc h3, includes a powerful error detection code / error correction code (edc/ecc), based on the bose, chaudhuri and hocquenghem (bch) algorithm. both edc and ecc are implemented in hardware to optimize performance. each time a 512-byte sector is written, additional parity bits are calculated and written to the flash. each time data is read from the flash, the pa rity bits are read and us ed for calculating error locations. it ensures that the minimal amount of code is used for detection and correction to deliver the required reliability withou t degrading performance. 3.6 block device management block device management is performed by an embedded sw module, responsible for execution of all block device operations, such as address calculation, erase, read and writes operations etc. this module translates these operations from virtua l media terms (i.e. sector addresses) to flash media terms (i.e. flash planes, blocks and pages). these block device operations are typically initia ted by the host file system, translated by the doc driver and sent to the device over the host interface. the host agent (above) is responsible for capture and transfer to the block device management.
rev. 1.3 data protection and security-enabling features mdoc h3 efd featuring embedded trueffs data sheet 29 92-ds-1205-10 4. d ata p rotection and s ecurity -e nabling features 4.1.1 read/write-protected partitions data and code protection is implemented on a pe r-partition basis. the user can configure each partition as read protected, write prot ected, or read and write protected. a protected partition may be protected by either/both of these mechanisms: ? up to 64 bit protection key ? hard-wired lock# signal ? sticky lock (slock) in order to set or remove read/write protecti on, the protection key must be used as follows: ? insert the protection key to remove read/write protection ? remove the protection key to set read/write protection the only way to read or write from/to a partition that is protected against read or write, is to insert the key. this is also true for modifying its attributes (protection ke y, read, write and lock). read/write access is disabled (the key is automa tically removed) in each of the following events: ? power-down ? removal of the protection key for further information on protection, please refer to the doc driver 1.0 block device (bd) software development kit (sdk) developer guide. 4.1.2 lock# signal mdoc h3 has an additional hardware safety m easure. if the lock option is enabled for a specific partition, and the lock# si gnal is asserted, the protected partition has an additional hardware lock that prevents read /write access to the partition, ev en with the use of the correct protection key. 4.1.3 sticky lock (slock) it is possible to set the lock protection for one session only; that is, unt il the next power-up or reset. this sticky lock feature can be useful wh en the boot code in the boot partition must be read/write protected. upon power-u p, the boot code must be unprotected so the cpu can run it directly from mdoc h3. at th e end of the boot process, protection can be set until the next power-up or reset. this is done by setting the st icky lock (slock) bit in the software lock register, or using a dedicated s/w api, and has the same effect as asserting the lock# signal. once set, slock can only be cleared by asser ting the rstin# input. like the lock# input, assertion of this bit prevents the protection key from disabling the protection for a given partition. there is no need to mount th e partition prior to this operation.
rev. 1.3 data protection and security-enabling features mdoc h3 efd featuring embedded trueffs data sheet 30 92-ds-1205-10 4.1.4 unique identification (uid) number each mdoc h3 is assigned a 16-byte uid numbe r. burned onto the flash during production, the uid cannot be altered and is worldwide unique. the uid is essential for security-related applications, and can be used to identify e nd-user products in orde r to fight fraudulent duplication by imitators. 4.1.5 one-time programmable (otp) partitions otp feature is implemented on a per-partition basis, for full flexibility. once a partition has been defined as otp (upon initial media-formatting), it can be written only once, after which it is automatically and permanently locked. after it is locked, the otp partit ion becomes read only, just like a rom device. regardless of the state of a ny of the lock options, otp partitions cannot be erased. typically, the otp partition is used to store customer and product information such as: product id, software version, production data, customer id, pki keys, service provider information and tracking information.
rev. 1.3 mdoc h3 modes of operation mdoc h3 efd featuring embedded trueffs data sheet 31 92-ds-1205-10 5. m doc h3 m odes of o peration figure 7 shows the different modes of mdoc h3 device operation and th e interchange between optional modes. mdoc h3 can operate in any one of five basic power modes/states: ? reset state ? turbo mode ? power save mode ? standby mode ? deep power-down mode figure 7: operation modes state machine
rev. 1.3 mdoc h3 modes of operation mdoc h3 efd featuring embedded trueffs data sheet 32 92-ds-1205-10 the above power modes are separated into two main groups: ? work mode group ? in which the device is active and performs various transactions. ? idle mode group ? in which the device is not active. the power mode is determined as follows: ? assertion of the rstin# signal se ts the device in reset state. ? upon power up the device enters it s pre-configured work mode. ? default work mode is turbo mode. the default can be changed to powersave mode and vice-versa using s/w api. ? once in any idle mode the device will move to work mode upon any transaction. it may return to idle mode upon inactivity, if so configured. ? entry and exit to/from deep power- down mode is described below. 5.1 reset state while in reset state, mdoc h3 ignores all write transactions and returns undefined values in response to any read access. 5.2 turbo mode this mode is defined as a "work mode" and is op timized for performance. all internal clocks are set to maximal work frequency. in this mode all standard operations i nvolving the flash memory can be performed. 5.3 power save mode this mode is defined as a "work mode" and is optimized for balance between power consumption and performance. balance is achiev ed by setting internal clocks to predefined optimal settings. in this mode all standard operations i nvolving the flash memory can be performed. 5.4 standby mode mdoc h3 enters standby mode upon device inac tivity. in standby mode the clock of most internal cores is either disconn ected or reduced to a minimum. there is no wake-up time penalty when switching back to working mode.
rev. 1.3 mdoc h3 modes of operation mdoc h3 efd featuring embedded trueffs data sheet 33 92-ds-1205-10 5.5 deep power-down mode while in deep power-down (dpd) mode, the quiescent power dissipati on of the mdoc h3 device is further reduced by disa bling internal high current cons umers (e.g. voltage regulators, input buffers, oscillator etc.) entering deep power-down mode is done by either of the following: ? writing to power_dn bit in the power mode register. ? activating a sw api to put the device immediately in dpd. ? setting auto dpd mode by sw. depending on auto dpd mode chosen the device will either enter dpd upon device inactivit y, or enter standby mode upon device inactivity and switch to dpd after a configurable peri od of inactivity. entering deep power-down mode and then returni ng to the previous mode does not affect the value of any register. exiting deep power-down mode is done using one of the following methods: ? performing a read/write access from/to mdoc h3. ? rstin# assertion.
rev. 1.3 embedded trueffs technology mdoc h3 efd featuring embedded trueffs data sheet 34 92-ds-1205-10 6. e mbedded t rue ffs t echnology 6.1 general description sandisk?s patented trueffs technology was designed to maximize the benefits of flash memory while overcoming inherent flash limitations th at would otherwise re duce its performance, reliability and lifetime. trueffs emulates a hard disk making flash transactions completely transparent to the os. in addition, since doc dr iver operates under the os file system layer, and exports standard block device api, it is completely transparent to the application. trueffs is now embedded within the mdoc h3 device, eliminating the need for complicated software integrations and enabli ng a practically plug & play inte gration with the system. mdoc h3 with embedded trueffs handles all the comple xity of flash management for the host sw. this dramatically simplifies software integration and test. it also allows for cost reductions to be achieved in projects using mdoc by upgrading to newer generati ons of mdoc devices based on newer and more cost effective nand technologies . the embedded flash management offered by trueffs assures that software on the host syst em or mass production tools need not to be changed or re-qualified when flash technology is changed. mdoc sw suppor t includes: ? drivers support for all major oss ? doc driver software developm ent kit (doc driver sdk) ? trueffs 7.1 software development kit (trueffs 7.1 sdk) ? one sw package to support both earlier mdoc technologies (s uch as g3, g4 and h1) and mdoc h3. ? support for all major cpus, including 16 and 32-bit bus architectures embedded trueffs technology features: ? flash management ? bad-block management ? dynamic virtual mapping ? dynamic and static wear-leveling ? power failure management ? implementation of edc/ecc ? performance optimization 6.2 operating system support the doc driver is integrated into all ma jor oss, including sy mbian, microsoft windows mobile, windows ce, linux and others. for a complete listing of all availa ble drivers, please contact your local sandisk sales office or distributor.
rev. 1.3 embedded trueffs technology mdoc h3 efd featuring embedded trueffs data sheet 35 92-ds-1205-10 6.3 doc driver software development kit (sdk) doc driver software development kit (sdk) provides the source code for the doc driver. it can be used in an os-less environment or when special customization of the driver is required for proprietary oss. the doc driver sdk is us ed also for utilizing mdoc h3 as the boot device. trueffs 7.1 software development kit (trueffs 7.1 sdk) provides the doc driver code, bundled with the trueffs code needed to support earlier mdoc tec hnologies (such as g3, g4 and h1) as well. 6.3.1 file management doc driver accesses the flash memory within mdoc h3 through either 8kb or 128kb window in the cpu memory space, depending on the mdoc h3 configuration. doc driver provides block device api by using standard file system ca lls, identical to those used for a hard disk, to enable reading from and writing to mdoc h3. this makes mdoc h3 compatible with any file system and file system utilities, such as diagnostic tools and applications. note: mdoc h3 is shipped unforma tted and contains virgin media. 6.3.2 bad-block management since nand flash is an imperfect storage media, it can contain bad blocks that cannot be used for storage because of their high error rates. embedded trueffs automatically detects and maps out bad blocks upon system initialization, ensuring th at they are not used for storage. during run- time, if additional bad blocks are detected they are automatically retired and replaced by blocks that are located in a pool of spares. this manage ment process is completely transparent to the user, who is unaware of the existence and locatio n of bad blocks, while remaining confident of the integrity of data stored. 6.3.3 wear-leveling flash memory can be erased a limited numb er of times. this number is called the erase cycle limit , or write endurance limit , and is defined by the flash de vice vendor. the erase cycle limit applies to each individual eras e block in the flash device. in a typical application, and espe cially if a file system is us ed, specific pages are constantly updated (e.g., the pages that contain the fat, regi stry, etc.). without a ny special handling, these pages would wear out more rapidl y than other pages, reducing th e lifetime of the entire flash. to overcome this inherent deficiency, embe dded trueffs uses sandis k?s patented wear- leveling algorithm. this wear-leveling algorithm ensures that consecutive writes of a specific sector are not written physically to the same pa ge in the flash. this spreads flash media usage evenly across all pages, thereby maximizing flash lifetime. dynamic wear-leveling embedded trueffs uses statistical allocation to perform dynamic wear-leveling on newly written data. this means that new data will be written to flash units which are less worn out.
rev. 1.3 embedded trueffs technology mdoc h3 efd featuring embedded trueffs data sheet 36 92-ds-1205-10 static wear-leveling areas on the flash media may contain static files, characterized by blocks of data that remain unchanged for very long periods of time, or even for the whole device life time. if wear-leveling were only applied on newly written pages, static areas would ne ver be cycled. this limited application of wear-leveling w ould lower life expectancy signif icantly in cases where flash memory contains large static areas. to overc ome this problem, embedded trueffs forces data transfer in static areas as well as in dynamic areas, thereby appl ying wear-leveling to the entire media. 6.3.4 power failure management embedded trueffs uses algorithms based on ?erase af ter write? instead of "erase before write" to ensure data integrity during normal operation a nd in the event of a power failure. used areas are reclaimed for erasing and writing the fl ash management information into them only after an operation is complete. this procedure se rves as a check on data integrity. the ?erase after write? algorithm is also used to update and store mapping information on the flash memory. this keeps the mapping information coherent even during power failures. the only mapping information held in ram is a table pointing to the location of the actual mapping information. this table is reconstructed during power-up or after reset from the information stored in the flash memory. to prevent data from being lost or co rrupted, embedded trueffs uses the following mechanisms: ? when writing, copying, or erasing the flash de vice, the data format remains valid at all intermediate stages. previous data is never erased until the operation has been completed and the new data has been verified. ? a data sector cannot exist in a partiall y written state. the operation is either successfully completed, in which case the new sector contents are valid, or the operation has not yet been completed or has failed, in which case the old sector contents remain valid. in addition, embedded trueffs applie s a unique algorithm to ensure th at new data written to the device will not affect any data al ready programmed to the device. 6.3.5 error detection/correction embedded trueffs implements a unique error corr ection code (ecc) algorithm to ensure data reliability. refer to section 3.5 for further information on the edc/ecc mechanism. 6.3.6 special features through i/o control (ioctl) mechanism in addition to standard storage device func tionality, the doc driver provides extended functionality. this functi onality goes beyond simple data storag e capabilities to include features such as: formatting the media, read/write prot ection, boot partition(s) access and other options. this unique functionality is av ailable in all doc drivers th rough the standard i/o control command of the native file system.
rev. 1.3 embedded trueffs technology mdoc h3 efd featuring embedded trueffs data sheet 37 92-ds-1205-10 6.3.7 compatibility migrating from mdoc g3/g4/h1 and mdoc g3/g4 -based mcp to mdoc h3 and mdoc h3 -based mcp can be done by trueffs 7.1. trueffs 7.1 supports all mdoc product line in cluding mdoc g3/g4/h1 and mdoc h3. doc driver 1.0 and higher provi des stand alone sw support for mdoc h3 only. it does not support mdoc g3/g4 and h1. when using different software modules (e.g. block device doc driver, boot application, formatting utilities, etc.) to access mdoc h3 it is crucial to verify that all software modules are based on the same code base version. it is also important to use only tools (e.g. dformat, dinfo, dimage, etc.) from the same version as the doc drivers used by the application. failure to do so may lead to unexpected results, su ch as lost or corrupted data. the driver version can be verified by the sign-on messages displaye d, or by the version information presented by the driver or tool. 6.4 128kb memory window mdoc h3 utilizes a 128kb memo ry window in the cpu address space, consisting of four 32kb sections as depicted in figure 8. the addresses described here are relative to the absolute starting address of the 128kb memory window. the 32kb programmable boot block (xip) is alia sed to section 0, 2 and 3. the sections are aligned to addresses 00000h, 10000h and 18000h a dditionally the second half of section 1 contains the second half of the ip l. this is done in order to enab le additional flex ibility in the ipl addressing schemes. for compatibility with next generation mdoc h3 devices, it is recommended to use only 8kb of the 32kb programmable boot block. address 8000h + offset is the base address fo r the mdoc h3 register s used for communication with the mdoc h3 device (excluding the paged ram registers).
rev. 1.3 embedded trueffs technology mdoc h3 efd featuring embedded trueffs data sheet 38 92-ds-1205-10 ipl ram (host xip) 00000h 32k / 4 x 8k 128k window ipl ram ? upper area (host xip) ipl ram alias (host xip) ipl ram alias (host xip) 10000h 18000h 32k / 4 x 8k 32k / 4 x 8k 0c000h 16k h3 registers 16k 08000h 1ffffh section 0 section 1 section 2 section 3 figure 8: mdoc h3 128kb memory map note: in future mdoc h3, ipl ram size is 8kb. for backward compatibility with the memory map, each 32k window is composed of 8k ipl and 3 additional aliases.
rev. 1.3 embedded trueffs technology mdoc h3 efd featuring embedded trueffs data sheet 39 92-ds-1205-10 6.5 8kb memory window for the purposes of backward compatibility, md oc h3 can present an 8kb memory window in the cpu address space, depicted in figure 9. the addresses describe d here are relative to the absolute starting address of the 8kb memory window. the 2kb programmable boot block (xip) in section 0 is alig ned to address 0000h. address 0800h + offset is the base address for the h3 registers used for communication with the mdoc h3 device (excluding the paged ram registers). ipl ram (host xip) 0000h 2k 8k window rsrvd 1800h 4k 2k h3 registers 0800h 1fffh section 0 s e c t i o n 1 section 2 figure 9: mdoc h3 8kb memory map
rev. 1.3 mdoc h3 registers mdoc h3 efd featuring embedded trueffs data sheet 40 92-ds-1205-10 7. m doc h3 r egisters this section describes various mdoc h3 registers and their functions. table 3: various mdoc h3 registers address (hex) 128kb window address (hex) 8kb window width (bits) register name 0030 8 paged ram command 0070 8 paged ram select 0080 8 paged ram unique id download 9400/9422 1400/1422 16 chip identification [0:1] 9402/9424 1402/1424 16 burst write/read mode control 9404 1404 16 burst write mode exit 940c 140c 16 dpd wakeup trigger register 9416 1416 16 dpd activation register 940e 140e 16 dma control 9418 1418 16 dma negation 9410 1410 16 software lock 9412 1412 16 endian control 7.1 definition of terms the following abbreviations and terms are used within this section: rfu reserved for future use. this bit is u ndefined during a read cycle and ?don?t care? during a write cycle. rfu_0 reserved for future use; when read, this bit always returns the value 0; when written, software should ensure that this bit is always cleared to 0. rfu_1 reserved for future use; when read, this bit always returns the value 1; when written, software should ensure that this bit is always set to 1. reset value refers to the value immediately pr esent after moving from reset state to one of the work modes. 7.2 reset values the reset value written in the register descrip tion is the register valu e after mdoc h3 moves out from reset state and enters one of the wo rk modes. registers for which a value is not defined after moving from reset state to one of the work modes, are marked by an n/a reset value.
rev. 1.3 mdoc h3 registers mdoc h3 efd featuring embedded trueffs data sheet 41 92-ds-1205-10 7.3 registers description this section describes various mdoc h3 registers and their functions. 7.3.1 paged ram command register description: this 8-bit register is used to enable write to other paged ram registers. address (hex): 0030 (both 8k b window and 128kb window) type: write d7 d6 d5 d4 d3 d2 d1 d0 read/write w w w w w w w w bit name command reset value n/a bit no. description command command the value 71h must be written to enable a subsequent write cycle to the paged ram page select register. all other values: reserved. 7.3.2 paged ram select register description: this 8-bit register is used to initiate a download operati on of the specified 1kb page. if the value 71h is not writte n to the paged ram command register immediately before writing this regist er, the write cycle will be ignored. address (hex): 0070 (both 8k b window and 128kb window) type: write d7 d6 d5 d4 d3 d2 d1 d0 read/write w w w w w w w w description seq page reset value n/a 00h bit no. description seq sequential indication. setting this bit initia tes a download from the next_page pointer of the previously downloaded page. the val ue written to the page field is ignored. page only significant when writing a 0 to the seq field. only value 00h is supported. page value of 00h loads the same data as in hardware or software reset.
rev. 1.3 mdoc h3 registers mdoc h3 efd featuring embedded trueffs data sheet 42 92-ds-1205-10 7.3.3 paged ram unique id download register description: writing to this 8 bit register initiates a download of the 16-byte unique identification (uid) number to offset 0 of the downloadable section of the ipl ram. after polling for ready status, the requested data may be read from the ipl ram. writes to this register will be ignored if the prior bus cycle was not a write cycle to the paged ram command register w ith data 71h (intervening ram read cycles are allowed). address (hex): 0080 (both 8k b window and 128kb window) type: write d7-d0 read/write w bit name rfu_0 reset value n/a 7.3.4 chip identification (id) register [0:1] description: these two 16-bit registers are used to identify the mdoc device residing on the host platform. they always return the same value. chip identification register [1] holds the bit inverse of chip identification register [0]. address (hex): 128kb window: 9400 / 9422 8kb window 1400 / 1422 type: read only d15-d0 read/write r bit name chipid / chipid inverse reset value chip identification register[0]: 4833h chip identification register[1] ? bit inverse: b7cch 7.3.5 burst mode control registers (read & write) description: these 16 bit regi sters contain the parameters for the burst transactions. there is one register for bur st write and one for burst read. the structure of both registers is the same. address (hex): 128kb window: 9424 (b urst read) / 9402 (burst write) 8kb window: 1424 (burst r ead) / 1402 (burst write) type: read / write
rev. 1.3 mdoc h3 registers mdoc h3 efd featuring embedded trueffs data sheet 43 92-ds-1205-10 d15-d14 d13 d12-d11 d10-d8 d7-d6 d5-d4 d3-d2 d1 d0 read/write r r/w r/w r/w r r r r/w r bit name rfu hold length latency rf u wait_state rfu bst_en rfu reset value 0 0 0 0 0 0 0 0 0 hold see section 9.8.2. length see section 9.8.2. latency see section 9.8.2. wait_state see section 9.8.2. burst_en enables burst mode cycles. 0: burst mode is disabled. 1: burst mode is enabled. note: burst mode can only be used in conjunction with mdoc h3 dma functionality. 7.3.6 burst write mode exit register description: write to this 16-bit register takes the devi ce out of burst write mode address (hex): 9404 (128kb window) / 1404 (8kb window) type: write d15-d0 read/write w bit name rfu reset value n/a note: burst mode can only be used in conj unction with mdoc h3 dma functionality. 7.3.7 dpd wakeup trigger register description: this 16-bit register selects the device wake up trigger from dpd mode. address (hex): 940c (128kb window) / 140c (8kb window) type: read / write bit number d15-d9 d8 d7-d0 read/write r r/w r bit name rfu wake_up_sel_bit rfu reset value 0 0 0
rev. 1.3 mdoc h3 registers mdoc h3 efd featuring embedded trueffs data sheet 44 92-ds-1205-10 wake_up_sel_bit selects the device wake up trigger 0: mdoc h3 ce# is the wakeup trigger. 1: read access (ce# & oe# assertion) or write access (ce# and we# assertion) is the wakeup trigger. 7.3.8 dpd activation register description: this 16-bit register is used to put mdoc h3 into deep power down mode. address (hex): 9416 (128kb window) / 1416 (8kb window) type: read / write bit number d15-d1 d0 read/write r w bit name rfu power_dn reset value 0 0 power_dn setting this bit to ?1? will put th e device to deep power down mode. 7.3.9 dma control register description: this 16-bit register cont rols the dma_req signal to the host. address (hex): 940e (128kb window) / 140e (8kb window) type: read / write bit number d15-d9 d8-d4 d3 d2 d1 d0 read/write r r/w r r/w r/w r/w bit name rfu pulse_width rfu edge dma_pol dma_en reset value 0 4 0 0 1 0 pulse_width the width of the dmarq# signal will be: pulse_width * icmu_clk (cycle ). maximum 32 icmu clocks. note: if the value is zero then dmarq# signal will not be asserted. edge level or edge: 0: level ? dmarq# will be asserted w hen data is ready and will be de-asserted before the end of the data according to dma_prog_neg (dma negation). 1: edge ? dmarq# will be generated for t he number of clock specified in the pulse_width field. dma_pol dmarq# polarity: 0: active high
rev. 1.3 mdoc h3 registers mdoc h3 efd featuring embedded trueffs data sheet 45 92-ds-1205-10 1: active low dma_en dma enable bit: 0: dmarq# is disabled 1: dmarq# is enabled 7.3.10 dma negation register description: this 16-bit register controls the negation of dmarq# signal to the host. address (hex): 9418 (128kb window) / 1418 (8kb window) type: read / write bit number d15-d10 d9-d0 read/write r r/w bit name rfu dma_prog_neg reset value 0 4 dma_prog_neg dma programmable negation: 0-1023: number of words in drq blo ck before end of data transfer that dmarq# signal will be negated. note: dma negation must be smaller than transfer size in words (16bit). 7.3.11 software lock register description: this 16-bit register implements the sticky lock functionality. after setting it, protected-partitions can no longer be accessed, until the device is reset. address (hex): 9410 (128kb window) / 1410 (8kb window) type: read / write bit number d15-d1 d0 read/write r r/w bit name rfu slock reset value 0 0 slock sticky lock bit. 0: sticky lock is not active 1: sticky lock is activated this bit can only be set once by the host until device is reset.
rev. 1.3 mdoc h3 registers mdoc h3 efd featuring embedded trueffs data sheet 46 92-ds-1205-10 7.3.12 endian control register description: this 16-bit register is used to control the swapping of the low and high data bytes when reading or writing with a 16-bit host. this provides an endian- independent method of enabling/di sabling the byte swap feature. address (hex): 9412 (128kb window) / 1412 (8kb window) type: read / write bit number d15-d9 d8 d7-d1 d0 read/write r r/w r r/w bit name rfu swap rfu swap reset value 0 0 0 0 swap swap enable per byte. (this bit can be set by setting bit-0 or bit-8). to clear the bit both bits 0 & 8 need to be cleared to ?0?; 0: data from host is unchanged. 1: data from host is swapped.
rev. 1.3 booting from mdoc h3 mdoc h3 efd featuring embedded trueffs data sheet 47 92-ds-1205-10 8. b ooting from m doc h3 8.1 introduction mdoc h3 can function both as a flash disk and as the system boot device. if mdoc h3 is used both as a flash disk and as the system boot device , it contains the boot loader, an os image and a file system. in such a configuration, mdoc h3 can serve as the only non-volatile device on board. when using mdoc h3 as the system boot device, the cpu fetches the first instructions from the mdoc h3 programmable boot block, which cont ains the ipl. the ipl handles the required platform initializations, and then loads the requir ed image or os boot loader from its dedicated partition. sandisk?s doc driver, sdk and utilities enable the construction of a proper mdoc h3 layout in order to support the b oot sequence. for a complete description of these tools, refer to the doc driver 1.0 block device (bd) so ftware development kit (sdk) developer guide and the doc driver 1.0 software utilities developer guide. these tools enable the following operations: ? formatting mdoc h3 ? creating multiple partitions for different st orage needs (ipl, boot loader, os images files, and fat partitions) ? programming the os image file figure 10 illustrates an example of a boot sequence. boot loader os image flash disk partition (os image storage) flash disk partition (file storage) power-up ram basic system initialization b oot loader copies os image to ram os start-up code mdoc h3 copy image to ram take image from mdoc figure 10: system boot sequence with mdoc h3
rev. 1.3 booting from mdoc h3 mdoc h3 efd featuring embedded trueffs data sheet 48 92-ds-1205-10 8.1.1 asynchronous boot mode host platforms should use asynchronous boot m ode when using mdoc h3 as the system boot device. during platform initialization, certain cpus wake up in 32-bit mode and issue instruction fetch cycles continuously. an intel pxaxxx cpu, for ex ample, initiates a 16-bit read cycle, but after the first word is read, it conti nues to hold ce# and oe# asserted while it increments the address and reads additional data as a burst. once in asynchronous boot mode, the cpu can fetch its instruction from the mdoc h3 programmable boot block. after reading from this block and completing the boot, mdoc h3 returns to derive its internal clock signal from the ce#, oe#, and we# inputs. please refer to section 10 for read timing specificati ons for asynchronous boot mode. 8.1.2 paged ram boot the paged ram boot feature uses the ipl sr am as two 1kb sections. the first section provides constant data, while the other section can be downloaded sequentially with flash data. one application of this featur e is to support secure boot re quirements. the paged ram boot feature does not require s upport of the busy# output. after a hardware or software reset, mdoc h3 initializes the first 2kb of xip ram with data stored in the first 2kb of th e pre-programmed ipl. the page d ram boot feature permits 1kb virtual pages (up to 254kb total) to be downloaded sequentially to the xip ram, upon receiving the proper command seque nce. since the mdoc h3 busy # output is not asserted by a page-load operation, a polling procedure is re quired to determine when the download is complete. an xip operation from the mdoc h3 ram is not supported during this polling operation, so it must be executed from system ram or rom instead. when two mdoc h3 devices are cascaded, pa ged ram downloads occur only on the first mdoc h3 device in the cascaded configuration (device-0). for more information on booting from mdoc h3 in paged ram boot mode, please contact your local sandisk sales office.
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 49 92-ds-1205-10 9. d esign c onsiderations 9.1 general guidelines ? a typical risc processor memory archite cture may include the following devices: ? mdoc h3 : contains the os image, applications, registry entries, back-up data, user files and data, etc. it can also be used to perform boot operati on, thereby replacing the need for a separate boot device. ? cpu : mdoc h3 is compatible with all major cpus in the mobile phone, digital tv (dtv), digital still camera (dsc), mp3, gps and other portable consumer electronics applications markets, including: ? arm-based cpus ? texas instruments omap, dbb ? intel pxaxxx family ? infineon xgold family ? analog devices (adi) digital baseband devices ? freescale i.mxxx applicat ion processors and i.xx digital baseband devices ? zoran er4525 ? renesas sh mobile ? emp platforms ? qualcomm msmxxxx ? boot device : in case mdoc h3 is not used as a boot device, rom or nor flash that contains the boot code is required for syst em initialization, kernel relocation, loading the operating systems and/or ot her applications an d files into the ram and executing them. ? ram/dram memory : this memory is used for code execution. ? other devices : a dsp processor, for example, may be used in a risc architecture for enhanced multimedia support. 9.2 configuration the configuration interface enables the designer to configure mdoc h3 to operate in different modes. ? the id0 signal is used in a cascaded configuration. ? the lock# signal is used for ha rdware write/read protection 9.3 demux (standard) interface mdoc h3 uses a nor-like interface that can easily be connected to any microprocessor bus. with a demux interface, it requires 16 address lines, 16 data lines and basic memory control signals (ce#, oe#, we#), as shown in figure 11 below. typically, mdoc h3 can be mapped to any free 128kb memory space (8kb address space requires less address lines).
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 50 92-ds-1205-10 for power connectivity please refer to mdoc h3 power supply conn ectivity in section 9.5. figure 11: demux system interface notes: 1. mdoc h3 is an edge-sensitive device and care should be taken to prevent excessive ringing on the ce#, oe# and we # signals. if required, these signals should be properly terminated (according to board layout; serial/parallel or both terminations) to avoid ringing 2. address line a0 should either be conn ected to the host cpu a0 or to gnd. 9.4 multiplexed interface with multiplexed interface, mdoc h3 requires the signals shown in figure 12 below. for power connectivity please refer to mdoc h3 power supply connectivity in section 9.5. figure 12: multiplexed system interface
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 51 92-ds-1205-10 note: mdoc h3 is an edge-sensitive device an d care should be taken to prevent excessive ringing on the ce#, oe# and we# signals. if required, these si gnals should be properly terminated (according to board layout; seria l/parallel or both terminations) to avoid ringing. 9.5 mdoc h3 power supply connectivity mdoc h3 can be configured to support differe nt combinations of core (vcc) and io (vccq) voltages. table 4 lists the connectivity required to s upport the different available combinations. table 4: power connectivity and capacitors power supply vcc vccq vcc1 vcc2 c+, c- core: 3.3v io: 3.3v 3.3v recommended: 0.1uf and 10nf capacitors 8 3.3v recommended: 0.1uf and 10nf capacitors required:1uf capacitor recommended: additional 0.1uf capacitor 9 3.3v 8 no capacitor 10 core: 3.3v io: 1.8v 3.3v recommended: 0.1uf and 10nf capacitors 8 1.8v recommend: 0.1uf and 10nf capacitors required: 1uf capacitor recommended: additional 0.1uf capacitor 9 3.3v 8 no capacitor 10 core: 1.8v io: 1.8v 1.8v required: 0.1 uf or 0.33 uf 14 recommended: additional 10nf capacitor 1.8v recommended: 0.1uf and 10nf capacitors 1.8v no capacitor 11 required: 1uf or 1.5uf capacitor recommended: additional 0.1uf capacitor 12 required: 33nf or 47nf capacitor 13 notes: 1. voltages listed above are nominal voltages. 2. capacitors that are listed as required mu st be installed. failure to install these capacitors will cause the device to fail. 3. the values of capacitors listed as required are critical for proper operation of the device. the values listed are the minimum required values and may be increased. however any major deviations from the va lues specified above should be verified with sandisk. 4. the values of capacitors listed as reco mmended may be modified based upon the specific behavior of the system power supply and board layout. these are bypass capacitors and they are required to mini mize ripples on the power supply inputs. failure to provide adequate bypass capacitors may cause intermittent problems. designs that have been validated with diffe rent capacitor configurations do not need to follow these recommendations. 5. all capacitors are assumed to have a worst case tolerance of +/- 20%. 6. we recommend using an x7r type capaci tor for all capacitors listed above.
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 52 92-ds-1205-10 7. the series inductance of th e capacitors marked as requi red should be less than 15nh. 8. for this configuration, we recommend that the 0.1uf capacitor will be located close to the vcc ball and the 10nf capacitor will be located close to the vcc2 ball. if this placement is not possible then both capacitors should be located as close as possible to the vcc ball. the 10nf capacitor is only recommended in order to reduce high frequency noise. 9. for compatibility with next generation md oc h3 devices we recommend adding an additional 0.1uf capacitor in parallel with th e required 1uf capacito r. for designs that will only use the current mdoc h3 devi ce only the 1uf capacitor is required. 10. in this configuration the in ternal charge pump is disabl ed. installing a 33nf or 47nf capacitor will have no impact on the device. 11. in this configuration the vo ltage regulator is disabled and no capacitors are required on this ball. installing a capacitor on this ball will have no impact on the device. 12. in this configuration the internal char ge pump is enabled. the current mdoc h3 device requires at least a 1uf capacitor on vcc2 but it can also be operated with 1.5uf capacitor. however, for sded5-aaab -ccc devices, a 1.5uf will be required. the 0.1uf capacitor is only recommended in order to reduce high frequency noise. 13. this capacitor is critical for the operation of the internal charge pump. for the current mdoc h3 device a 33nf capacitor is required but it can also be operated with a 47nf capacitor. however, for for sded5-aaab- ccc devices, a 47nf capacitor will be required. 14. for the current mdoc h3 device a 0.1uf cap acitor is required but it can also be operated with a 0.33uf capacitor. however, f for sded5-aaab-ccc devices, a 0.33uf capacitor will be required. this applies only to 1.8v core and i/o configuration. 15. in case there are multiple ba lls available for a power supply then the recommended capacitors do not need to be duplicated for all balls but can be placed near one or more balls. 16. for systems that use a cascaded configurat ion, each mdoc h3 device must have its own set of required capacitors. required capacitors cannot be shared between devices. capacitors that are recommended can be shared between devices, however their effectiveness may be reduced. carefu l analysis of the potential noise on the power supply pins should be conducted be fore deciding to share capacitors and reduce the total number of recommended capacitors. 17. the capacitors must be placed as close as possible to the package leads. below are some drawings that depict the various power connectivity opti ons. all options are valid for both mux and demux configurations. 18. busy#, dmarq# and irq# should not be pulled up to any voltage higher than vccq.
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 53 92-ds-1205-10 host host control figure 13: mdoc h3 power connection for 3.3v core/3.3v i/o figure 14: mdoc h3 power connection for 3.3v core/1.8v i/o
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 54 92-ds-1205-10 host host control figure 15: mdoc h3 power connection for 1.8v core/1.8v i/o
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 55 92-ds-1205-10 9.6 connecting control signals 9.6.1 demux interface when using a demux nor-like interface, c onnect the control signals as follows: ? a[16:0] ? connect these signals to the host address si gnals (see section 9.10 for platform-related considerations). the a0 si gnal may be connected to either the host cpu a0 signal or to vss. ? d[15:0] ? connect these signals to the host data signals (see section 9.10 for platform-related considerations). ? oe# (output enable) and write enable (w e#) ? connect these signals to the host rd# and wr# signals, respectively. ? ce# (chip enable) ? connect this signal to the memory address decoder. most risc/mobile processors include a programma ble decoder to generate various chip select (cs) outputs for di fferent memory zones. these cs signals can be programmed to support different wait st ates to accommodate mdoc h3 timing specifications. ? rstin# (power-on reset in) ? connect this signal to the host active-low power-on reset signal. ? id0 (chip identification) ? this signal mu st be connected to vss if the host uses only one mdoc h3. if more than one de vice is being used, refer to section 9.9 for more information on device cascading. ? busy# (busy) ? this signal indicates when the device is ready fo r first access after reset. it may be connected to an input port of the host, or alternatively it may be used to hold the host in a wait-state condition. th e later option is required for hosts that boot from mdoc h3. ? dmarq# (dma request) ? output used to control multi-page dma operations. connect this output to the dma c ontroller of the host platform. ? irq# (interrupt request) ? connect this signal to the host interrupt. ? lock# (lock) ? connect to a logical 0 to prevent the usage of the protection key to open a protected partition. connect to logical 1 in order to enable usage of protection keys. ? clk (clock) ? this input is used to suppor t burst operation when reading flash data. refer to section 9.8 for further information on burst operation. 9.6.2 multiplexed interface mdoc h3 can use a multiplexed interface to connect to a multiplexed bus. in this configuration, mdoc h3 avd# signal is driven by the host's avd# signal, and the d[15:0] balls, used for both address inputs and data, are co nnected to the host ad[15:0] bus. this mode is automatically entered when a fa lling edge is detected on avd#. this edge must occur after rstin# is negated and before oe# and ce# are both asserted; i.e., the first read
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 56 92-ds-1205-10 cycle made to mdoc must observe the multiplexed mode protocol. see section 10 for more information about the related timing requirements. please refer to section 2.3 for ballout and signal de scriptions, and to section 10 for timing specifications for a multiplexed interface. 9.7 implementing the interrupt mechanism 9.7.1 hardware configuration to configure the hardware for working with th e interrupt mechanism, the irq# ball should be connected to a host interrupt input. 9.7.2 software configuration irq# signal may be used by mdoc h3 to inte rrupt the host system, provided that device interrupts are enabled. interrupts can be enabled or disabled using the flhwconfig doc driver api. for more information see the doc driver 1.0 block device (bd) software developer kit (sdk) developer guide. when asserted, the irq# signal will remain asserted until cleaned (level only). this cleaning is performed automa tically by the doc driver as part of the api (read or write) completion. mdoc h3 will interrupt the host system in the following cases: ? device is ready to receive a data block (e xcluding the first) during write operation. ? when using dma transfers: ? on completion of block device operation to mdoc h3. ? device is ready to send a data block during a read operation. 9.8 dma and burst operation mdoc h3 enhances performance using vari ous proprietary techniques among them are ? burst operation to read or write large c hunks of data, providing a burst speed. ? dma operation to release the cpu for other ta sks in coordination with the platform?s dma controller. this is especially useful during the boot stage. up to 128kb of data can be transferred during a dma operation. 9.8.1 dma operation mdoc h3 provides a dmarq# output that enables data transfer using the host dma controller. during dma operation, the dmarq# output is used to notify the host dma controller that data is re ady to be read or written. mdoc h3 protocol enables such data transfer up to the maximal size of 128kb per read or write operation. the dmarq# output sensitivity is selected by setting the edge bit in the dma control register: 1. edge dmarq# output pulses to indicate to the dma controller that a data is ready to be transferred. the edge bit is se t to 1 for this mode. the amount of data that will be transferred corresponds to data block size.
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 57 92-ds-1205-10 2. level dmarq# output is asserted while the da ta is available for r ead, or data can be accepted for write. the edge bit is set to 0 for this mode. the following steps are required in or der to initiate a dma operation: 1. if the dma controller supports an edge-sensitive dmarq# si gnal, then initialize the dma controller to transfer 512 bytes (or your chosen data block size) upon each dma request. if the dma controller supports a level-sensit ive dmarq# signal, then initialize the dma controller to transfer data conti nuously while dmarq# is asserted. 2. set in the dma control register values of edge bit, pulse_width and dma polarity corresponding to settings of the host dma c ontroller. this can be done only once after system power-up. 3. enable dma transfer with dma_en bit in the dma control register. 4. if host dma controller detects the de-asse rtion of the dmarq# signal too late (and attempts to transfer additional words as a result ), then dmarq# can be configured to be de- asserted earlier by using the dma negation register. 5. program host dma controller to transfer the same number of sectors as will be given in following logical command. 6. issue the dma data-transfer read/write command w ith same number of sectors to transfer as given in the previous step (prior to this, the device should be instructed to perform transfers in dma-mode). upon command completion irq# will be asserted (it is recommended to use irq# when working with dma). in case of a failure, less th an expected amount of da ta could be transferred. in commands that use dma transfer, irq# is activated only at the completion of the whole command; while in commands that do not use dma transfer irq# is typically activated with every data transfer. default setting of dmarq# is level and active-low. it can be modified using the flhwconfig doc driver api. for more information see the doc driver 1.0 block device (bd) software developer kit (sdk) developer guide.. 9.8.2 synchronous burst operation in this mode the host reads full sections of 16-bit words synchronized to the clk input. burst operation is controlled by 5 bit fields in ea ch burst mode control register (one for burst read and one for burst write): burst_en , wait_state, latency, hold and length. for full details on this regist er, please refer to section 7. burst read / write mode is enabled by setting the burst_en bit in each burst mode control register.
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 58 92-ds-1205-10 9.8.2.1 read mode the latency field controls the number of clock cycles between mdoc h3 sampling ce# being asserted and when the first word of data is available to be latched by the host. this number of clock cycles is e qual to 3 + latency. wait_state allows setting the number of clk af ter the host has read the last word until the release of the ce#. ? 1: one clk clock before ce# release ? 2: two clk clocks before ce# release ? 3: three clk clocks before ce# release the hold bit in the burst mode control register can be set to hold each data word valid for two clock cycles rather than one. note: if hold = 1, then the data is available to be latched on this clock and on the subsequent clock. the length field must be programmed with th e length of the burst to be performed (0 corresponds to 4 cycles; 1 to 8 cy cles, 2 to 16 and 3 corresponds to 32 cycles). each burst cycle must read exactly this number of words. the clk input can be toggled continuously or can be halted. when halting the clk input, the following guidelines must be observed: ? the host must provide a cloc k signal for the full sequence defined by the latency, wait state, hold and lengt h bit fields. the clock can only be stopped after the release of ce#. ? the clock can be halted momentarily duri ng a burst sequence but the host must provide rising clock edges for the completion of the burst sequence. note: for full information regarding the synchronous burst mode see the doc driver 1.0 block device (bd) software developer kit (sdk) developer guide . figure 16: demux read burst mode
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 59 92-ds-1205-10 valid address d0 d1 d2 d3 d4 d5 d6 d7 burst clk ce oe avd data latency=1 figure 17: multiplexed read busrt mode notes: 1. note: avd must be asserted on the follo wing clock after the assertion of ce. 2. no collision should be allowed between the avd and oe signal. 9.8.2.2 write mode the write mode is similar to the r ead mode with the following exceptions: ? wait_state = 0: 1 clock added. ? wait_state = 1: 2 clocks added. ? wait_state = 2: 3 clocks added. ? wait_state = 3: 4 clocks added. figure 1818: demux write burst mode note: we is sampled on the 1 st clock after ce assertion. it must be active (low) for at least one clock cycle, after that the status of the we signal is not important (?).
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 60 92-ds-1205-10 figure 19: multiplexed write burst mode 9.9 device cascading up to two devices can be cascaded w ith no external decoding circuitry. figure 19 illustrates the configuration required to cascad e two devices on the host bus (only the relevant cascading signals are included in this figure, although all other signals must al so be connected). all balls of the cascaded devices must be wired in common, ex cept for id0. the id ball values determine the identity of each device ? the first device is identified by connecting th e id ball as 0, and the second device by connecting the id ball as 1. systems that use only one mdoc h3 should connect id0 to gnd. figure 19: mdoc h3 cascaded configuration id0 ce# oe# we# ce# we# oe# v ss id0 ce# oe# we# vccq 2nd 1st
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 61 92-ds-1205-10 9.10 platform-specific issues this section discusses hardware design issues for major embedded risc processor families. 9.10.1 wait state wait states can be implemented only when mdoc h3 is designed in a bus that supports a wait state insertion, and s upplies a wait signal. 9.10.2 big and little endian systems mdoc h3 is a little endian devi ce. therefore, byte lane 0 (d[7:0]) is its least significant byte (lsb) and byte lane 1 (d[15:8]) is its most signif icant byte (msb). within the byte lanes, bit d0 and bit d8 are the least significant bits of their respective byte lanes. mdoc h3 can be connected to a big endian de vice in one of two ways: 1. make sure to identify byte lane 0 and byte lane 1 of your pro cessor. then, connect the data bus so that the byte lanes of the cpu matc h the byte lanes of m doc h3. pay special attention to processors that also change the bit ordering wi thin the bytes (for example, powerpc). failing to follow these rules result s in improper connection of mdoc h3, and prevents the doc driver from identifying it. 2. if needed, set the swap bits in the endian control register. this enables byte swapping when used with big endian 16-bit hosts. 9.10.3 busy signal the busy signal (busy#) indicates that mdoc h3 has not yet completed internal initialization. after reset, busy# is asserted while the ipl is downloaded into the in ternal boot block. once the download process is completed, busy# is de-asserted. it can be used to delay the first access to mdoc h3 until it is rea dy to accept valid cycles. note: mdoc h3 does not use this signal to in dicate that the flash is in busy state (e.g. program, read, or erase). 9.10.4 working with 16/32-bit systems mdoc h3 uses a 16-bit data bus and supports 16 -bit data access by default. however, it can be configured to support 32-bit data access mode. th is section describes th e connections required for each mode. the default of the doc driver for mdoc h3 is se t to work in 16-bit mode. it must be specially configured to support 32-bit mode. please s ee doc driver or trueffs 7.1 documentation for further details. note: the mdoc h3 data bus must be connected to the least significant bits (lsb) of the system.
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 62 92-ds-1205-10 16-bit (word) data access mode the mdoc h3 is 16 bit wide device. all accesse s to and from the device are 16 bit wide. mdoc h3 address lines should be connected to system host address lines, as depicted in figure 20. mdoc h3 a0 line should be co nnected either to system host sa0 address line, or to vss. system host mdoc h3 sa16 a0 note: the prefix ?sa? indicates system host address lines figure 20: 16-bit data access mode 32-bit (double word) data access mode in a 32-bit bus system that cannot execute word -aligned accesses, the system address lines sa0 and sa1 are always 0. consecutive double word s (32-bit words) are differentiated by sa2 toggling. therefore, in 32-bit systems that s upport only 32-bit data ac cess cycles, mdoc h3 signal a1 is connected to the first syst em address bit that toggles; i.e., sa2. mdoc h3 address lines should be connected to system host address lines, as depicted in figure 21. mdoc h3 a0 line should be connected either to system host sa1 address line, or to vss system host note: the prefix ?sa? indicates system host address lines figure 21: address shift configurat ion for 32-bit data access mode
rev. 1.3 design considerations mdoc h3 efd featuring embedded trueffs data sheet 63 92-ds-1205-10 9.11 design environment mdoc h3 provides a complete de sign environment consisting of: ? evaluation boards (evbs) for enabling soft ware integration and development with mdoc h3, even before the target platform is available. ? programming solutions: ? programmer o programming house o on-board programming o doc driver software development kit (sdk) ? trueffs 7.1 software development kit (sdk) ? xp utilities: o dformat o dimage o dinfo ? documentation: o data sheet o application notes o technical notes o articles o white papers please visit the sandisk website ( www.sandisk.com ) for the most updated documentation.
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 64 92-ds-1205-10 10. p roduct s pecifications 10.1 environmental specifications 10.1.1 operating temperature table 5: operating temperature product ordering info temperature range md2534-xxx-yy - 40c to +85c sde-zz-xxxy-bbb -25c to +85c 10.1.2 thermal characteristics table 6: thermal characteristics thermal resistance ( c/w) junction to case ( jc ): 40 junction to ambient ( ja ): 90 10.1.3 humidity 10% to 90% relative, non-condensing. 10.2 electrical specifications 10.2.1 absolute maximum ratings table 7: absolute maximum ratings parameter symbol rating units 1.8v dc supply voltage vcc1 -0.3 to 2 v 3.3v dc supply voltage vcc2 -0.3 to 4 v 1.8/3.3v dc supply voltage vccq -0.3 to 4 v 1.8/3.3v dc supply voltage vcc -0.3 to 4 v maximum duration of applying only part of the power supplies (some of the power supply on and the other off) t 1supply 500 msec input pin voltage vin -0.3 to 3.6 v ambient temperature otr -25 * to 85 c storage temperature tstg -55 to +125 c * for md2534-xxx-yy products the value is -40 o c notes: 1. permanent device damage may occur if absolute maximum ratings are exceeded. exposure to absolute maximum rating conditions for extended periods may affect device reliability.
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 65 92-ds-1205-10 2. when operating mdoc h3 with separate power supplies for vccq/vcc/vcc1/vcc2, it is recommended to turn the supplies on and off simultaneously. providing power separately (either at power-on or power-off) can cause excessive power dissipation. damage to the device may result if this condition persists for more than 500 msec. 10.2.2 capacitance table 8: capacitance symbol parameter conditions min typ max unit c in input capacitance v in = 0v 10 pf c out output capacitance v o = 0v 10 pf 10.2.3 dc characteristics 10.2.3.1 1.8v core, 1.8v i/o table 9: 1.8v core, 1.8v i/o symbol parameter conditions min typ max unit vccq i/o power supply 1.65 1.8 1.95 v vcc2 internal supply nc nc nc - vcc device supply 1.65 1.8 1.95 v vcc1 internal supply 1.65 1.8 1.95 v vih input high-level voltage 0.65* vccq 0.3+ vccq v vil input low-level voltage -0.3 0.35* vccq v ii input leakage current 0 vin vccq -10 10 ua ioz tri-state output leakage current 0 vin vccq -10 10 ua vhys hysteresis schmidt trigger inputs 400 mv voh high-level output voltage ioh=4ma- 12ma vccq- 0.45 v vol low-level output voltage ioh=4ma- 12ma 0.45 v pu pull up resistance 95 149 261 k ? pd pull down resistance 77 135 312 k ? turbo mode 30 75 icc active supply current 1 power save mode 20 65 ma standby mode 5 10 ma i ccs standby supply current 1 dpd mode 75 130 ua note: sum of all current on v cc, vccq and vcc1 balls. c l = 0 pf. t=25c.
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 66 92-ds-1205-10 10.2.3.2 3.3v core, 1.8v i/o table 10: 3.3v core, 1.8v i/o symbol parameter conditions min typ max unit vccq i/o power supply 1.65 1.8 1.95 v vcc2 internal supply 2.7 3.3 3.6 v vcc device supply 2.7 3.3 3.6 v vcc1 internal supply nc nc nc - vih input high-level voltage 0.65* vccq 0.3+ vccq v vil input low-level voltage -0.3 0.35* vccq v ii input leakage current 0 vin vccq -10 10 ua ioz tri-state output leakage current 0 vin vccq -10 10 ua vhys hysteresis schmidt trigger inputs 400 mv voh high-level output voltage ioh=4ma- 12ma vccq- 0.45 v vol low-level output voltage ioh=4ma- 12ma 0.45 v pu pull up resistance 95 149 261 k ? pd pull down resistance 77 135 312 k ? turbo mode 30 60 icc 3 active supply current 1 power save mode 20 40 ma standby mode 5 10 ma i ccs 3 standby supply current 1 dpd mode 60 130 ua notes: 1. sum of all current on vcc, vccq and vcc2 balls. c l = 0 pf. t=25c. 2. for all products with ordering info sde- zz-xxxy-bbb, icc and i ccs parameters are estimations.
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 67 92-ds-1205-10 10.2.3.3 3.3v core, 3.3v i/o table 11: 3.3v core, 3.3v i/o symbol parameter conditions min typ max unit vccq i/o power supply 2.7 3.3 3.6 v vcc2 internal supply 2.7 3.3 3.6 v vcc device supply 2.7 3.3 3.6 v vcc1 internal supply nc nc nc - vih input high-level voltage 2.0 3.6 v vil input low-level voltage -0.3 0.8 v ii input leakage current 0 vin vccq -10 10 ua ioz tri-state output leakage current 0 vin vccq -10 10 ua vhys hysteresis schmidt trigger inputs 520 mv voh high-level output voltage ioh=4ma- 12ma 2.4 v vol low-level output voltage ioh=4ma- 12ma 0.4 v pu pull up resistance 50 65 100 k ? pd pull down resistance 40 56 107 k ? turbo mode 30 60 icc active supply current 1 (cycle time = 60 ns) power save mode 20 40 2 ma standby mode 5 10 ma i ccs standby supply current 1 dpd mode 110 150 ua note: sum of all current on v cc, vccq and vcc2 balls. c l = 0 pf. t=25c.
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 68 92-ds-1205-10 10.3 timing specifications 10.3.1 operating conditions timing specifications are based on the conditions defined in table 12. table 12: operating conditions parameter 1.8v 3.3v ambient temperature (ta) -40c to +85c -40c to +85c supply voltage (vccq) 1.65v ? 1.95v 2.7v ? 3.6v clk, scs#, si, so, sclk 3ns 3ns input fall and rise time (10%- 90% vccq) all other inputs 5ns 5ns input timing level vccq/2 vccq/2 output timing level vccq/2 vccq/2 output load push/pull outputs 30pf 30pf note: max input fall and rise is 100ns.
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 69 92-ds-1205-10 10.3.2 demux asynchronous read timing figure 22: demux asyn chronous read timing a 0 a 1 d0 d1 tacc (ipl_ram) tacc (ipl_ram) tdh tsua ce oe a ddress data figure 23: demux read timing ? asynchronous boot mode table 13: demux asynchronous read timing parameters symbol 1.8v 3.3v description min max min max units tsua address setup time ( figure 22) 1 1 ns tsua address setup time ( figure 23) ? asynchronous boot mode -2 -2 ns tacc(async) asynchronous access time (registers) 18 15 ns tacc(ipl_ram) ram access time 25 22 ns tdh data hold time 1.5 10 1.5 10 ns tah address hold time 0 0 ns tw(ceh) ce# high pulse width 10 10 ns tw(cel) ce# low pulse width 20 15 ns tw(oeh) oe# high pulse width 10 10 ns tw(oel) oe# low pulse width 20 15 ns note: tw(cel) must be greater than or equal to tw(oel).ce# falling edge sh ould together with or before oe# falling edge, not after.
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 70 92-ds-1205-10 10.3.3 demux asynchronous write timing figure 24: demux asynchronous write timing table 14: demux asynchronous write timing parameters 1.8v 3.3v symbol description min max min max units tasu address setup 1 1.2 ns tah address hold time 3 3 ns tdsu data setup 11 11 ns tdh data hold 0 0 ns tw(ceh) ce# high pulse width 10 10 ns tw(cel) ce# low pulse width 15 15 ns tw(weh) we# high pulse width 10 10 ns tw(wel) we# low pulse width 15 15 ns note: tw(cel) must be greater than or equal to tw(wel). 10.3.4 multiplexed asynchronous read timing address valid d0 tacc tdh tah tasu tavdoe tavd tavd tw (oeh) tw (oeh) tw (oel) tw (oel) ce oe a vd data figure 25: multiplexed asynch ronous read timing diagram
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 71 92-ds-1205-10 a 0 d0 tdh tdsu tah tasu tavdwe tavd tavd tw(weh) tw(wel) tw(weh) tw(wel) ce we a vd data table 15: multiplexed asynchronous read timing parameters 1.8v 3.3v symbol description min max min max units tasu address setup 3 2 ns tah address hold 5 5 ns taccs access time 15 13 ns tdh data hold 1.5 1.4 ns tavd avd# pulse width 6 6 ns tw(oel) oe# low pulse width 15 15 ns tw(oeh) oe# high pulse width 10 10 ns tavdoe avd rising to oe falling 6 6 ns 10.3.5 multiplexed asynchronous write timing figure 26: multiplexed asynch ronous write timing diagram table 16: multiplexed asynchronous write timing parameters 1.8v 3.3v symbol description min max min max units tasu address setup 3 2 ns tah address hold 5 5 ns tdsu data setup time 12 11 ns tdh data hold 0 0 ns tavd avd# pulse width 6 6 ns tw(wel) we# low pulse width we# should be negated before or together with ce# 15 15 ns tw(weh) we# high pulse width 5 5 ns tavdwe avd rising to we falling 1 1 ns
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 72 92-ds-1205-10 10.3.6 demux burst read timing figure 27: demux burst read timing diagram table 17: demux burst read timing parameters 1.8v 3.3v symbol description min max min max units tasu address setup 4 4 ns tah address hold 2.5 2.5 ns tcesu ce# setup 9 9 ns tacc access time 11.2 8.1 ns tcyc burst clock cycle time 14 11 ns tdh data hold time 2 2 ns notes: 1. all timing specifications are with reference to the rising edge of the burst clock (clk signal). 2. shown with the following burst mode control register (read) parameters: ? hold = 0 ? length = 8 ? latency = 0 ? wait_state = 0 3. this diagram is applicable only if working with continuous clock. 4. burst clock cycle time (tcyc) values are specified for turbo mode. while in power- save mode, clock cycle time should be doubled.
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 73 92-ds-1205-10 10.3.7 demux burst write timing a0 d0 d1 d2 d3 tdh tdsu tweh twesu tah tasu tces u tcyc tcyc burst clk ce ad dre s s we data figure 28: demux burst write timing diagram table 18: demux burst write timing parameters 1.8v 3.3v symbol description min max min max units tasu address setup 4 4 ns tah address hold 2.5 2.5 ns tcesu ce# setup 7 7 ns twesu we# setup time 4 4 ns tweh we# hold time 5 5 ns tcyc burst clock cycle time 12.5 12.5 ns tdsu data setup time 4 4 ns tdh data hold time 2.5 2.5 ns notes: 1. all timing specifications are with reference to the rising edge of the burst clock (clk signal). 2. shown with the following burst mode control register (read) parameters: ? hold = 0 ? length = 8 ? latency = 0 ? wait_state = 0 3. this diagram is applicable only if working with continuous clock. 4. burst clock cycle time (tcyc) values are specified for turbo mode. while in power- save mode, clock cycle time should be doubled.
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 74 92-ds-1205-10 10.3.8 multiplexed burst read timing valid address d0 d1 d2 d3 d4 d5 d6 d7 tacc tdh tah tasu tavdh tavdsu tcesu tcyctcyc burst clk ce oe avd data figure 29: multiplexed burst read timing diagram table 19: multiplexed burst read timing parameters 1.8v 3.3v symbol description min max min max units tasu address setup 4 4 ns tah address hold 2.5 2.5 ns tcesu ce setup 9 9 ns tacc access time 11 8 ns tcyc burst clock cycle time 12.5 12.5 ns tdh data hold time 2 2 ns tavdsu avd setup time 7 7 ns tavdh avd hold time 1 1 ns notes: 1. all timing specifications are with reference to the rising edge of the burst clock (clk signal). 2. shown with the following burst mode control register (read) parameters: ? hold = 0 ? length = 8 ? latency = 1 ? wait_state = 0 3. burst clock cycle time (tcyc) values are specified for turbo mode. while in power- save mode, clock cycle time should be double.
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 75 92-ds-1205-10 10.3.9 dma request timing diagram 10.3.9.1 asynchronous data transfer table 20 lists dma request timing parameters and figure 30 shows the dma request timing diagram in asynchronous data transfer. tp(ce/oe) tw(dmarq)tw(dmarq) ce/oe dmarq# figure 30: dma request timing diagr am (asynchronous data transfer) table 20: dma request timing parameters (asynchronous data transfer) 1.8v 3.3v symbol description min max min max units tw(dmarq) dmarq# pulse width 1 20 20 ns tp(ce/oe) ce/oe to dmarq# negation 2 19 16 ns notes: 1. applies to edge mode only. the dmarq# pulse width can be configured by sw. 2. applies to level mode only. values refer to rising of ce or oe signal, which ever negated first. 10.3.9.2 synchronous data transfer table 21 lists dma request timing parameters and figure 31 shows the dma request timing diagram in synchronous data transfer. tp(bc lk) tw (dmarq) tw (dmarq) bclk d ma rq# clk figure 31: dma request timing diagram (synchronous data transfer) table 21: dma request timing parameters (synchronous data transfer) 1.8v 3.3v symbol description min max min max units tw(dmarq) dmarq# pulse width 1 20 20 ns tp(bclk) clk to dmarq# negation 2 17 13 ns notes: 1. applies to edge mode only. the dmarq# pulse width can be configured by sw. timing is relative to the rising edge of clk which samples ce# asserted. 2. applies to level mode only.
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 76 92-ds-1205-10 10.3.10 spi timing table 22 lists spi slave timing parameters. figure 32 and figure 33 show the spi slave timing diagram. table 22: slave spi timing parameters symbol 1.8v 3.3v description min max min max units notes tw(sclk1) sclk high pulse width 15 15 ns tw(sclk0) sclk low pulse width 15 15 ns tcyc(sclk) sclk period 40 40 ns tsu(si) si to sclk setup 8 8 ns tho(si) sclk to si hold 8 8 ns tsu(scs#) scs# to sclk setup 8 8 ns tho(scs#) sclk to scs# hold 16 16 ns tw(scs#1) scs# high pulse width 16 16 ns tp(so1) sclk to so ? delay 22 17 ns tp(so0) sclk to so delay 22 16 ns thiz(so) scs# ? to so hi-z 12 10 ns thiz(so) tp(si0) tp(si1) tho(si) tsu(si) tw(scs#1) tw(scs#1) tw(sclk1) tw(sclk1) tw(sclk0) tw(sclk0) tw(sclk0) tcyc(sclk) tw(sclk0) tw(sclk1) tw(sclk1) tcyc(sclk) sclk (mode 0,3) sclk (mode 1,2) scs# si so figure 32: slave spi data timing
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 77 92-ds-1205-10 figure 33: slave spi control timing 10.3.11 power supply sequence when operating mdoc h3 with separate power supplies powering the vccq, vcc, vcc1 or vcc2 rails, it is desirable to turn the supplie s on and off simultaneousl y. providing power to one supply rail and not the other (either at powe r-on or power-off) can cause excessive power dissipation. damage to the device may result if this condition persists for more than 500 msec. 10.3.12 power-up timing mdoc h3 is reset by assertion of the rstin# input. when this signal is negated, mdoc h3 initiates a download procedure from the flash memory into the internal programmable boot block. during this procedure, mdoc h3 doe s not respond to read or write access. host systems must therefore observe the requir ements described below for initial access to mdoc h3. any of the following methods may be employed to guarantee first-access timing requirements: ? use a software loop to wait at least tp (busy1) before accessing the device after the reset signal is negated. ? poll the state of the busy# output. ? use the busy# output to hold the host cpu in wait state before initiating the first access which will be a ram read cycle. at least one of the signals ce# and oe# must be kept negated (high) until busy# is negated. hosts that use mdoc h3 to boot the system must employ the latter option or use another method to guarantee the required timing of initial access.
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 78 92-ds-1205-10 table 23: power-up timing parameters symbol description min max units t rec (vcc-rstin) vcc/vccq stable to rstin# ? 1 500 p s t w (rstin) rstin# asserted pulse width 50 ns t p (busy0) rstin# to busy# 50 ns t p (busy1) rstin# ? to busy# ? 3 75 ms t p (vcc-busy0) vcc/vccq stable to busy# 500 p s tsu (rstin-avd) rstin# ? to avd# ? 2 3 p s tsu (busy-ce) busy# ? to ce# 0 p s trise (rstin) rstin# rise time 20 ns notes: 1. specified from the final positive crossi ng of vcc/vcc1/vcc2/vccq minimum voltages. 2. applies to multiplexed interface only. 3. t p (busy1) depends on ipl mode (norma l / paged ) and device capacity. for unformatted devices this time may be up to one second. figure 34: reset timin g
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 79 92-ds-1205-10 10.4 mechanical dimensions 10.4.1 mdoc h3 1gb (128mb)/2gb (256mb)/ 4gb (512mb) fbga 128mb (1gb) dimensions: 9.0 0.1 mm x 12.0 0.1 mm x 1.1 0.1 mm ball pitch: 0.8 mm 9.0 12.0 1.10.1 0.260.04 0.8 0.4 0.4 0.9 0.8 12345678910 0.460.05 top side bottom a b c d e f g h j k l m n p 0.8 0.20 s a 0.20 s b 0.10 s 0.10 s ? 0.06 m s ab 0.15 4x index b figure 35: mechanical dimensions 9x12 fbga package dimensions in mm symbol ordering info min nom max b md2534-d2g-x-p 0.41 0.46 0.51 b sded7-256m-n9 0.30 0.35 0.40 b sded5-512m-n9 0.30 0.35 0.40
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 80 92-ds-1205-10 10.4.2 mdoc h3 4gb (512mb)/8gb (1gb) fbga dimensions: 10.0 0.1 mm x 14.0 0.1 mm x 1.1 0.1 mm ball pitch: 0.8 mm 100.1 140.1 1.10.1 0.230.05 0.4 0.4 0.8 1.4 1.8 12345678910 0.350.05 top side bottom index a b c d e f g h j k l m n p 0.8 figure 36: mechanical dimensions 10x14 fbga package
rev. 1.3 product specifications mdoc h3 efd featuring embedded trueffs data sheet 81 92-ds-1205-10 10.4.3 mdoc h3 8gb (1gb)/ 16gb (2gb)/ 32gb (4gb) / 64gb (8gb) fbga dimensions: 12.0 0.1 mm x 18.0 0.1 mm x 1.3 0.1 mm ball pitch: 0.8 mm symbol ordering info max height(mm) h sded7-001g-nt 1.4 h sded7-002g-nt 1.4 h sded5-002g-nc 1.2 h sded5-004g-nc 1.2 h sded5-008g-nc 1.4 figure 37: mechanical dimensions 12x18 fbga package
rev. 1.3 ordering information mdoc h3 efd featuring embedded trueffs data sheet 82 92-ds-1205-10 11. o rdering i nformation see table 24 for mdoc h3 devices availabl e and the associated order information. table 24: mdoc h3 ordering information capacity ordering code mb mb package temperature range md2534-d1g-x-p md2534-d1g-x-p/y 128 1024 (1gbit) 9x12x1.2 bga 115 balls -40c to +85c sded7-256m-n9t sded7-256m-n9y 256 2048 (2gbit) 9x12x1.2 bga 115 balls -25c to +85c sded7-512m-nat sded7-512m-nay 512 4096 (4gbit) 10x14x1.2 bga 115 balls -25c to +85c sded5-512m-n9t sded5-512m-n9y 512 4096 (4gbit) 9x12x1.2 bga 115 balls -25c to +85c SDED5-001G-NAT sded5-001g-nay 1024 (1gb) 8192 (8gbit) 10x14x1.2 bga 115 balls -25c to +85c sded5-002g-nct sded5-002g-ncy 2048 (2gb) 16384 (16gbit) 12x18x1.2 bga 115 balls -25c to +85c sded5-004g-nct sded5-004g-ncy 4096 (4gb) 32768 (32gbit) 12x18x1.2 bga 115 balls -25c to +85c sded5-008g-nct sded5-008g-ncy 8192 (8gb) 65536 (64gbit) 12x18x1.4 bga 115 balls -25c to +85c notes: 1. sde product codes: t suffix specifies shipme nt in tape & reel; y suffix specifies shipment in trays. 2. md product codes:: y suffix specifies shipment in tr ays; if not specified, shipment is in tape & reel
rev. 1.3 markings mdoc h3 efd featuring embedded trueffs data sheet 83 92-ds-1205-10 12. m arkings 12.1 mdoc h3 1gb (128mb) markings for md2533-d1g xxx and md2533-d26g xxx products: first row: logo second row: product name third row: ordering information fourth row: production information: yyww - year and week xx - product status: engineering sample s ?-es?, customer samples ?-cs? forth row: ddddddd - internal marking figure 38: md2534-d1g-x-p product marking
rev. 1.3 markings mdoc h3 efd featuring embedded trueffs data sheet 84 92-ds-1205-10 12.2 mdoc h3 2gb (256mb)/ 4gb (512mb )/ 8gb (1gb)/ 16gb (2gb)/ 32gb (4gb) / 64gb (8gb) all products with ordering info of sde -zz-xxxy-bbb will have following marking: first row: logo second row: vywwxxxxn v-internal use y-year ww-work week xxxx ? internal use n-internal use third row: ordering information fourth row: internal use fifth row: country of origin i.e ?taiwan? or ?china? xx is ?es? or ?cs?. there will be no xx marking for products in mass production. figure 39: example of sded7-512m-na product marking
rev. 1.3 disclaimer of liability mdoc h3 efd featuring embedded trueffs data sheet 85 92-ds-1205-10 d isclaimer of l iability sandisk il ltd.?s general policy does not reco mmend the use of its pr oducts in life support applications wherein a failure or malfunction of the product may directly th reaten life or injury. accordingly, in any use of products in life suppor t systems or other applications where failure could cause damage, injury or loss of life, th e products should only be incorporated in systems designed with appropriate redundancy, fa ult tolerant or back-up features. sandisk il shall not be liable for any loss, injury or damage caused by use of the products in any of the following applications: special applications such as military related eq uipment, nuclear reactor control, and aerospace control devices for automotive vehicles , train, ship and traffic equipment safety system for disaster prevention and crime prevention medical-related equipment includi ng medical measurement device.
rev. 1.3 mdoc h3 efd featuring embedded trueffs data sheet 86 92-ds-1205-10 h ow to c ontact u s usa sandisk corporation, corporate headquarters. 601 mccarthy blvd milpitas, ca 95035 phone: +1-408-801-1000 fax: +1-408-801-8657 china sandisk china ltd. room 121-122 bldg. 2, international commerce & exhibition ctr. hong hua rd. futian free trade zone shenzhen, china phone: +86-755-8348-5218 fax: +86-755-8348-5418 europe sandisk il ltd. 7 atir yeda st. kfar saba 44425, israel tel: +972-9-764-5000 fax: +972-3-548-8666 internet sandisk.com/oem general information oemsupport@sandisk.com japan sandisk japan inc. asahi seimei gotanda bldg., 3f 5-25-16 higashi-gotanda shinagawa-ku tokyo, 141-0022 phone: +81-3-5423-8101 fax: +81-3-5423-8102 taiwan sandisk asia ltd. 14 f, no. 6, sec. 3 minquan east road taipei, taiwan, 104 tel: +886-2-2515-2522 fax: +886-2-2515-2295 sales and technical information oemsupport@sandisk.com this document is for information use only and is subject to change w ithout prior notice. sandisk il ltd assumes no responsibility for any errors that may appear in this document, nor fo r incidental or consequential damages resulting from the furnishing, perf ormance or use of this material. sandisk il?s products are not warr anted to operate without failure. sandisk il?s general policy does not recommend the use of its products in life support applic ations where a failure or malfunction of the product could cause injury or loss of life. per sandisk il?s terms and conditions of sale, the user of sandisk il ?s products in life support applications assumes all risk of such use and indemnifies sandisk il against all damages. see ?disclaimer of liabilit y". accordingly, in any use of the product in life support systems or other applications where failure could cause in jury or loss of life, the product should only be incorporated in systems designed with appropria te and sufficient redundancy or backup features. all parts of the sandisk il?s doc umentation are protected by copyri ght law and all rights reserved. contact your local sandisk sales office or distributor, or visit our website at www.sandisk.com to obtain the latest specifications before placing your order. ? 2007 sandisk il ltd. all rights reserved. trueffs, sandisk and sandisk logo are regist ered trademarks of sandisk il ltd. and sandisk corporati on, respectively. other product names or service ma rks mentioned herein may be trademarks or re gistered trademarks of their respective owners and are hereby acknowledged.

▲Up To Search▲

Price & Availability of SDED5-001G-NAT

	To Download SDED5-001G-NAT Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .